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

It's ok to use .csproj as input for msbuild. You can manually add tasks for it into csproj which will be ignored during compliting from VS. But if you're going to make some non trivial stuff it's better to create separate msbuild's scripts. And they can be referenced from csproj files. Did you have a look at MS Build Server which is part of TFS? It integrates with TFS's SourceControl and could be used for CI. Its project files are msbuild scripts.

If I did use nAnt, is it required that VS must be installed on the server? Did you mean 'MSBuild'? No, it's not necessarily to install VS for using msbuild with csproj files.

Answer 2

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.

Answer 3

I use both NAnt and MSBuild. NAnt was upgraded with NAntContrib so that I got msbuild taks. I may be temporary setup but so far I have not run in major problems. That said I also do not create a new csproj file because I use the same csproj/sln that I use in VS2008. Building projects with msbuild greatly simplified legacy NAnt scripts (we used csc task).

Notes:

1. If you use Windows Workflow Foundation in your projects you will have major difficulties build such project without msbuild.
2. Do not install VS.NET on your build machine. You can use Wix do create installation msi.
3. @Franci Penov: Running unit tests SHOULD be part of every build. Do you really want to wait until tomorrow to find a bug ? There is a side note: Unit tests should run very fast.

Answer 4

OK, few things to watch out for. The csproj format has changed from VS2005 to VS2008. Also if you are going with MSBuild, remember that you won't be able to build .vdproj (setup) files; for that you need devenv (the VS executable). That said you can always create a MSBuild task which calls devenv and builds it for you.

As for your question whether to build your own csproj file or use the one created by VS2005, I would suggest a middle road: create your own project template, which caters to your needs and let VS take care of the rest.

Answer 5

Create your own project file (anything that ends with *proj is considered a project file by MSBuild) and call your build from there. Like this:

<MSBuild Projects="MySolution.sln" Targets="Clean; Rebuild" Properties="Configuration=$(BuildMode);">

Note that msbuild can also build .sln (solution file) without any changes, which is usually easier than having a bunch of csproj files...

Answer 6

I personally think it's ok to go with the .csproj file. There's not that much going on in there that you wouldn't have to add yourself if rolling your own MSBuild project.

However, whatever route you decide to go, I'd still recommend to not add the MbUnit as part of your build step, but add it as a separate step in CC.Net. Running unit tests should be part of the daily CI cycle; however, it should not be part of every build.