Open Source Tools and Visual Studio 2008 / .NET 3.5

Since I have started consulting I have encountered a few projects that use open source tools fairly heavily.  It seemed to me that most of these tools now have equivalent counterparts in .NET 3.5.  Mind most of these were written between 2003 and now and Microsoft has been picking them up and adding them to the .NET Framework or Visual Studio.  So I asked the question of the other elegant coders.  "With so much stuff in .NET 3.5, why would I learn the Open Source tools instead of concentrating on what is in the framework?"

I specifically asked about the first 5 in the list below.  As other elegant coders replied, more were added to the list.

1. Nhibernate -> SQL Metal and Linq
2. Nant -> MSBuild. 
3. Castle Windsor -> System.AddIns
4. NUnit -> MSTest in VS 2008 Pro
5. NDOC -> Sandcastle

The first is the open source tool.  The second is the Microsoft equivalent.

-------------------------------------------------------------------------------------------------------------------

The final list turned out like this (as posted by Chris and David with comments below)

Note: Linq and Linq to SQL are different products.  Linq itself is not database specific, nor an orm.  Linq to SQL is built on top of Linq and is database specific and an (poor mans) ORM.

1. Nhibernate, SubSonic -> SQL Metal and Linq to SQL -> MS Data Entity Framework
2. Nant -> MSBuild, FinalBuilder
3. Castle Windsor, Spring.Net, StructureMap -> MS Unity IoC Framework
4. NUnit, MBUnit, XUnit.Net -> MSTest in VS 2008 Pro
5. NDOC -> Sandcastle
6. CruiseControl -> TeamCity -> Team Systems TeamBuild
7. SubVersion -> SourceSafe -> Team Systems

1. NHibernate: more configurable than Linq to SQL.  Also allows you to generate your database from your domain, which Linq to SQL does not, and Entity Framework doesn't yet (but will).   If you really want to compare apples to apples, compare LINQ to SQL to SubSonic and NHibernate to the Entity Framework.

2. Easier to find samples for Nant, and Nant can run C# code from the script.  FinalBuilder has a nice GUI for doing a lot of the same stuff.

3. Unity isn't going to be any easier to setup than the OSS tools for this one, and currently Unity is much less of a product (bare bones really).  Actually, Unity is sort of OSS itself (you can get the source, but I'd have to check the license again).  I like Spring.Net, but I'm taking a serious look at StructureMap and Castle Windsor right now.

4.  In 2005 you could only get MSTest with Team Systems -- fixed in 2008.  But again, MSTest isn't any easier to explain or use than NUnit, MBUnit, or XUnit.Net.  ReSharper has a beautiful support for NUnit (and support for XUnit.Net is coming).  I don't see an advantage to MSTest.

6. I <heart> TeamCity.  CruiseControl is a pain to setup the first time, but pretty easy after that.

7. Other people can answer that one better than me.

-------------------------------------------------------------------------------------------------------------------

As Jason and Scott pointed out the problem is the Open Source version of these can be a tough sell in an organization when you already have somewhat equivalent functionality already in the framework or being released by MS on CodePlex.

The primary issue I see is if I install the 3.5 ,NET framework I get the Microsoft version of the these tools built in.

• .SQL Metal and Linq to SQL -> MS Data Entity Framework
• MSBuild.
• System.AddIn (I know this is not technically a IOC container but it is pretty close).

If I pick up Visual Studio 2008 Professional I get

• MSTest in VS 2008 Pro. I have come to the conclusion that I am not as dedicated to TDD as Chris. :-).

Finally I do use

• CruiseControl
• SubVersion

Because I don't want to buy Team System for a one man shop. 

All in all I will still need to know the open source tools because they are in wide use, just like I seem to be acquiring third party user controls (Ifragistics, Componet One, Telerik) because my customers are using them. 

I will try to use the .NET framework tools as much as possible because, as Scott said:

Wow, everyone has made some pretty good comments, there is not much more I can add except for one point of view I did not see mentioned and I think Darrel was hinting at.  The point is or  word of the day is “cohesion”.   Microsoft’s .Net stack is maturing and they seem to be paying attention (for the most part) to very popular open source movements that are delivering some kick butt products and tools.   While the MS integrated offerings are not always best of breed (most feature rich) when compared to the before mentioned open source tools, they are nicely integrated i.e. high cohesion factor which can (but not always) translate into shorter training/learning curve and higher productivity.

I am a fan and have used and still use many of the open source tools mentioned here.   However, I am sure most of us can agree it does take a bit of effort to stitch together a string of these open source tools when building your engineering/development environment.  The integrated MS stuff is just there and is pretty easy to use.  Probably a bigger point is that finding people skilled in the majority of these open source tools/products can be quite changeling, as a few of us have recently experienced.   It is sad to say guys but we are not the typical developer.   The native/integrated MS solutions will become the standard given enough time and maturity.  At some point you will be hard pressed to find devs who have ever worked with the tools we have discussed here but there will be a good chance they know or have heard about the MS integrated offerings.  One of the new devs we hired was all excited telling me about sandcastle (I just had to listen made him feel good) when I told him it was nothing new they got the Idea from nDoc, his reply was nDoc what? 

I may be one who is just drinking the Kool-Aid here, but going the more pure MS tools approach definitely has its merits, once that particular product hits a certain maturity which lately is beta 1 ;-)