I have a bad habit of collecting links and awesome tweets in the Twitter favorites and never recording them elsewhere. This post, and others to follow in the series, are just a dump out of my favorites so they are permanently recorded somewhere.
I am an incredible believer in the need for build automation on projects. I believe that every developer should be commonly issueing a command, be that via PSake or rake or something else, which builds and tests the project outside the confines of Visual Studio. As such, MSBuild.exe is incredibly important, as it is how you compile your SLN files.
MSBuild.exe has moved…
In Visual Studio 2013, there is an amazingly important change that you must be aware of, or you will go insane trying to figure out what is going to. Microsoft has moved MSBuild to another directory! Now the reasons they’ve done this are all good, MSBuild.exe and the various compilers now are the responsibility of Visual Studio, not of the Framework itself. As such, instead of being located in C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe as you might normally expect on a 64-bit machine, it is instead located in C:\Program Files (x86)\MSBuild\12.0\bin\amd64\msbuild.exe.
But it has also NOT moved…
Unfortunately, because of dependencies from Visual Studio 2012, the path C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe also still has the executable. And if you run VS2013 projects through that version of MSBuild.exe then you will get errors, usually about unable to find some kind of MSBuild .targets file.
Please be careful, and adjust your builds accordingly.
I’m thrilled to announce that Devlin Liles and I have recently released an update to Highway.Data that is only a minor increment, but has a major new feature. It now contains a totaling In Memory version of our DataContext. This allows for much more interesting and easy unit testing, without the need to mock so many things.
Now, this is an introductory feature, and I’m sure there will be edge cases it won’t cover correctly. We welcome bug reports on GitHub, as well as pull requests.
I’m pleased to report that our first Fourth Friday Family Game Night (#FFFGN) was an incredible success. We had over 30 players, playing an assortment of games from Phase 10 to Dominion to Ticket to Ride Europe, and more.
We’ve opened sign ups for our next event, which will be July 26th, starting at 6pm until we get tired and go home. You can signup at:
We look forward to seeing even more of you at the July gathering. Again, in case you’re not familiar with the event, you can find the details here, but it is open to ANYONE. This last month we had someone show up who had just met an attendee in their apartment parking lot when they saw them carrying out a copy of Dominion. ANYONE is invited.
You are officially invited to join the consultants of Improving Enterprises for board games, fun and frivolity. Every 4th Friday of the month we will gather for a family friendly night of games. We’ll have drinks of all sorts available, and a large selection of games.
Who is invited?
Everyone, regardless of age or skill. Bring yourself, your kids, we’ve got games for all ages. We ask that you sign up, if possible, in advance just to give us an idea of how many people are coming. Our registration site is located at this link.
When is it?
The Fourth Friday of every month, hence the name. We’ll officially start at 6:00pm, and run until … well we’ll play alot of games. Leave when you’d like.
Where is it?
We’re hosted at Improving Enterprises, a fantastic company in the North Dallas area. Their offices are at:
Pretty much everything. If you’re idea of a board game is the traditional American board games of Monopoly or Risk, then we’ve got you covered.
On the other hand, if you’re a fan of Euro-style board games, then we’ve got people who would love to play a game of Dominion, Settlers of Catan, Small World, Agricola, or anything else you’d like to bring.
Are you an huge name on Board Game Geek? Bring your favorite game and teach us how to play!
I don’t know any of those games!
Great! We love to teach people how to play.
I’ve got questions still…
Contact one of our official Hosts, they’ll be more than happy to field any questions you might have:
Tim Rayburn can be reached at firstname.lastname@example.org or 817-760-0002
Ty Crockett can be reached at email@example.com
This event is graciously hosted by the incredible folks at Improving Enterprises. They open their offices, soda fridge, and other facilities to us on a monthly basis and we’re thrilled to have their support. If you’re an IT professional, please chat with on of their employees who attend to learn more about this great company.
Highway.Onramp.Services is part of the Onramp series of NuGet packages which all focus on providing you robust starting solutions for common team needs. They let you skip over all that required plumbing friction, and jump straight into writing code which produces real business value.
Now, we can’t do that without making some very important decisions for you. That’s why as part of this we’ve also produced Highway Onramper, which lets you create your own version of these Onramps with your own technology decisions made. For this post we’re just introducing our version, and in a future post we’ll teach you how to make an Onramp of your own.
1, 2, 3 Running Service
So let’s create a Windows Service, that we can actually debug, and install/uninstall, shall we?
Start Visual Studio and create a Console Application in C#. When you’re done, the Program.cs should look like the default:
static void Main(string args)
Open the Package Manager Console, and type:
PM> Install-Package Highway.Onramp.Services
Note: You will be prompted for permission to overwrite your Program.cs, go ahead and give permission, after all there is no useful code in that class yet.
File 'Program.cs' already exists in project 'ConsoleApplication4'. Do you want to overwrite it?
[Y] Yes [A] Yes to All [N] No [L] No to All [?] Help (default is "N"):Y
Overwrite existing file 'Program.cs'.
Successfully added 'Highway.Onramp.Services 188.8.131.52' to ConsoleApplication4.
Press F5 and run your new, fully functional, Windows Service.
INFO> Configuration Result:
[Success] Name MyService
[Success] DisplayName My Services Long Description
[Success] Description My Services Long Description
[Success] ServiceName MyService
INFO> Topshelf v184.108.40.206, .NET Framework v4.0.30319.18046
INFO> The MyService service is now running, press Control+C to exit.
INFO> Tick Tock goes the clock
INFO> Tick Tock goes the clock
INFO> Tick Tock goes the clock
INFO> Tick Tock goes the clock
That’s it, your service is up and running, and can be debugged. But what decisions did we just make for you?
Straight to Value
So before we explain how this all works, if you just want to get down to coding, then have at it. The file you want to modify is Services.cs and you can change everything about that class you want to EXCEPT that it implements the IHostedService interface. That is how our framework code tells your code when to Start and Stop.
As you can see, the default we’ve provided uses a simple Timer to write to the console. But you can wire in anything you want at this point.
First and foremost, your new service uses the amazing TopShelf project to turn a simple Console application into a Windows Service. I encourage you to go and learn more about this project, but the fundamentals are the following:
Install the service:
Uninstall the service:
We are big believers in Dependency Injection, and so we’ve included Castle.Windsor as an Inversion of Control container. But more than that, we’ve already setup a the container for the basics for you. If you go to the new Installers directory in your project, you will see three classes. All of these inherit from IWindsorInstaller and are invoked when the service starts to configure your container.
NLog & Castle Logging Facility
We’ve implemented the Castle Logging Facility, which is an abstraction over the top of any logger, and then wired that up to NLog. There is an NLog.config file, and it is already setup to log to a file, and the console, and the debugger at various levels of messages.
By default the console only receives Info level or higher, but the debugger will receive everything.
Also from Castle.Core, we’ve used Dictionary Adapter to provide a testable abstraction over App Settings. This is setup in the CastleInstaller.cs, with the following lines of code:
// Our configuration magic, register all interfaces ending in Config from
// this assembly, and create implementations using DictionaryAdapter
// from the AppSettings in our app.config.
var daf = new DictionaryAdapterFactory();
.Where(type => type.IsInterface && type.Name.EndsWith("Config"))
reg => reg.UsingFactoryMethod(
(k, m, c) => daf.GetAdapter(m.Implementation, ConfigurationManager.AppSettings)
This tells Castle to register all Types from the current assembly which are Interfaces and which have a name that ends with “Config”. It then says that when such an interface is resolved, it will use the DictionaryAdapterFactory to create an instance of this interface for you, backed by the AppSettings of your project. Now, you’re probably not familiar with DictionaryAdapter, but if you’d like to learn more I’d suggest my two blogposts of the subject.
We’ve included an interface example in the Config folder to show you how this might work:
As part of our efforts in creating the Highway Framework, Devlin and I have found that there is a related but not identical other problem we wanted to solve. Highway.Data serves as a library extension to Entity Framework, and other ORMs, but because its a library we didn’t fill it with a lot of our actual opinions on how to create working solutions. For instance, it isn’t bound to just one IoC, or Logging framework, etc.
In our next endeavor, Highway Onramps, we intend to make it possible to quickly kickstart applications with the architecture you’ve decided on, and we’ll show you how by letting you take our opinions. As part of this Onramps project, we are introducing three different projects, and a bunch of NuGet packages:
Highway.Onramp.MVC is our basic MVC solution, using MVC 4. Installed into a new project, it will bring in Castle.Windsor and wire-up everything needed for Dependency Injection.
Highway.Onramp.MVC.Logging adds Castle’s Logging Facility support, and wires into unhandled application errors, and logs start and stop events.
Yesterday at AgileDotNet, before one of my sessions, we were discussing books which every software developer should read with the room, and particularly with a bunch of SMU students who came down to Houston to attend. I promised I would post the list of those books to my blog, so here they are: