Starting Monday morning I will be starting a new project for a client of my employer Improving Enterprises.  I’ve spent a good deal of time talking with my new teammates about what technologies we will be using for the project, and I thought that work might be of interest to others, so here are some of the highlights.

Technology Stack : VS2010, .NET 4, C#

The first thing that was decided, during the initial scoping phase of the project, was that this project was a nearly ideal candidate for Visual Studio 2010 and .NET 4.0.  How did we come to that decision?  The desired architecture for the project is such that certain features of WCF 4.0 and Entity Framework 4.0 would help with the implementation, and the timeline of the project is such that we have a no concerns over the current lack of the a “Go Live” license.  For language it was decided we will primarily be working in C#. With that decided, we get to the far more interesting pieces.

Inversion of Control : StructureMap

Obviously we are going to need an IoC container for the project, and we have settled on StructureMap for that.  The competition in this regard was Castle Windsor as Improving has the benefit of employing Craig Neuwirt, we knew we had an expert.  The final decision to go with StructureMap instead hinged on two related things, complexity and learning curve.  While we were quite certain we could pick up Castle quickly enough (2 of the 3 did not know it already), we were not as certain how easy it would be for those who follow us.  StructureMap had a single well defined scope (IoC), versus the larger bite that the Castle Project would be for those who follow.  We recognize we could have just done Windsor, but we found no compelling reasons to do that versus StructureMap.

As noted, we will be doing a good bit of WCF 4.0 on this project, so it naturally followed we would need to integrated StructureMap into the channel stack to let it handle the creation of our service instances.  Jimmy Bogard has an excellent post on this subject, and we followed that guidance closely, though we updated the StructureMapServiceHostFactory to use ObjectFactory.Initialize as was recommended by the excellent ObsoleteAttribute usage in the latest StructureMap.

Source Control : GIT

Even within a group of people as passionate about creating great technology as we have at Improving, there are certain debates that deeply divide us.  Source Control is definitely one of them.  We have a certain segment of the company that are passionate advocates for Team System, obviously including Chris Tullier our resident Team System MVP.  But there are others who are passionate believers in Subversion.  Still others are not happy with either of those options, and still seek the “better mouse trap” for Source Control.  We discussed the pros and cons of various solutions and decided in the end to try GIT, because of its distributed model, and see how we liked it in comparison to the others.  It is an experiment, and we shall see.

Logging : log4net

Really, is there another option?  The definitive logging library for .NET, it does what it needs to and does not bring along any additional baggage.  As we are also using StructureMap, we found this blog post by John Rudolf Lewis helpful in discussing how to inject log4net using StructureMap (or Ninject) without losing fidelity in the logs.

Conclusion

So there are a few of our technology decisions, things I’ll be learning on in the coming months more and more.