MSBuild — Use the .csproj file or roll your own?

Question

OK, so I readily concede that I\'m a newbie when it comes to continuous integration.

That being said, I\'m trying to set up a CC.NET environment to educate myself, b

Answer 1

I would recommend using the generated .csproj files - in fact for production, I think using the generated .sln files is a good idea. I have found that you will you gain by using the same solution files as the developers.

Be aware that .sln files are not actually valid msbuild project files - they are transformed into msbuild projects by msbuild itself when they are used as inputs. Tricky!

For learning purposes, you may want to log the build of a .csproj and step through to get an idea of what is going on. MSBuild is a bit more declarative than nant though, so take your time and experiment a bit.

Finally, I would wrap your .sln or .csproj files in a continuous build script project with msbuild tasks to build your projects and run your unit tests together. This way the developers don't have to run the unit test every time they build - but every time they integrate their code the unit tests will run. And yes, make sure they run fast! Anything that takes more than a second should be run during a scheduled (nightly?) build instead. Likely they are less unit tests and more integration tests written with a unit test framework if they take more than a second.

Edit: Some addition information I have found that I have found useful - using MSBuild 3.5 will allow you to get the target output from a .sln file, while this information is not returned in MSBuild 2.0 (though I think it should work for .csproj files in both versions). You can use the output (your built files) as inputs to your unit testing framework.