How to move onto automated builds with Visual Studio?

Question

I work in at small .net shop where we currently build all our solutions using the visual studio IDE. We want to progress to a point where we're in complete control of our MSBuild scripts for build, test, deploy - making use of the MSBuild community tasks etc.

I guess my question is: what will be different in Visual Studio development experience?

If we're creating our own MSBuild .proj files, does that mean we no longer have .csproj files? How do projects look in VS now?

Am I missing something really obvious?

UPDATE Thanks all for taking the time to respond. I'm aware of some of the build tools out there: CruiseControl, TeamCity and so on, and also that vs projects (.csproj etc) are just MSBuild files. What I'm trying to get a handle on is those people who've decided to write their own scripts and their own .proj files. Are they using the VS .csproj files just as the 'container' to hold their code files within the IDE? How do they trigger their own developer builds? Do they just fire up MSBuild from the command line? Have a button on a toolbar that effectively does the same?

In summary - yes, you can indeed use other tools to drive your build by calling the .sln file or .csproj files, but there's another way - how does that work?

Answer 1

We use msbuild to do automated builds and you can just point msbuild at your solution file without any changes.

Also just to clarify, we also use an automated build server (Hudson with .Net plugins) that uses msbuild to automate the process.

Answer 2

You should look at CruiseControl.NET rather than rolling your own automated build and CI process. It makes like a lot easier and it can do extra stuff like run until tests or code coverage tools or whatever as part of the build process.

Answer 3

what will be different in Visual Studio development experience?

Nothing, typically. In fact, if you're doing it right, this should be transparent; your IDE shouldn't care what build manager you use. That's why solutions like CruiseControl.NET and Hudson are nice.

If we're creating our own MSBuild .proj files, does that mean we no longer have .csproj files? How do projects look in VS now?

Your solution structure remains the same. In Visual Studio, solutions and projects do double duty as a project-organization/packaging guide and as an IDE convenience. Your build manager will introspect this to understand what needs to be built.

Answer 4

There are several good automated and continuous build tools available, which build on MSBuild. Your C# project files already ARE MSBuild files - so in reality, since VS2005, you've been using MSBuild on your local workstation to create your build - you just might not have known about it :-)

Besides CruiseControl.NET (mentioned by JP) which is definitely worth a look, I'd also recommend two more products:

• FinalBuilder Server which seems to be almost unknown to the vast majority of developers (but it definitely deserves more attention! Excellent tool). They also have a stand-alone desktop version FinalBuilder if that's something you might need. It's not free - but at $100 for one user (and $450 for 5), it's really not a huge expenditure

• TeamCity by JetBrains - also well known for their Resharper product in the .NET world - which offers a free Pro version for teams up to 20 users/build plans, and a much more expensive Enterprise edition, if you've grown :-)

Compared to CruiseControl.NET, both offer nice, friendly GUI's to both configure your builds, as well as monitoring them.

And as I mentioned - both build on top of your existing project and solution file structure, so no need to change anything there at all.

You really can't go wrong with Continuous Integration! I couldn't be without the immediate build feedback anymore......

Marc

Answer 5

We use TeamCity at work; we started with CruiseControl.NET but switched when another developer pointed out to me that I would be maintaining the cc build forever otherwise. ;) Seriously, TeamCity is very easy to learn and use.

I asked similar questions when I first heard about continuous integration. Do you have to rewrite (and maintain) all the solutions and projects by hand? Do you need to learn MSBuild commands? The short answer is No.

As Mr. Harvey mentioned, you can simply call MSBuild on a VS-created solution or project file and it will build it for you. TeamCity will handle this automatically.

If you want more flexibility, I'd recommend NAnt. I have worked with hand-coding MSBuild scripts, and it's an exercise in frustration. NAnt has a cleaner syntax and (for me) is easier to use and read. We use NAnt for the fancy stuff and (again) call MSBuild from NAnt when we want to build a project or solution. TeamCity supports NAnt.

To summarize, for us nothing really changed in Visual Studio. We still create and maintain our projects and solutions in the same way. When we check them into source control (TFS), TeamCity automatically picks that up, builds the solutions, and runs our (NUnit) tests. We also have one-click deployment builds set up (in TeamCity using NAnt).

Answer 6

Thanks all for your responses, but with a bit of research I've found some ideas on ways to do it a bit differently:

• to extend the build process beyond the constraints of the .sln & .csproj files
• yet still use Visual Studio
• and keep within the MSBuild world as much as possible
• adding in the capabilities of build servers such as TeamCity and Hudson where required
• but not being reliant on these servers for functionality that a build script should provide.

So what I've found is: This older blog post from Scott Hanselman on code organisation. Here he's using Nant instead of MSBuild, but the underlying concept is to execute whichever nant/msbuild project you want via a .bat batch file.

"In this souce directory we've got things like build.bat and buildpatch.bat. The goal being that folks can get the stuff from source control and type BUILD and be somewhere useful. It's VERY comforting to be able to reliably and simply build an entire system."

From this I can see that he's (obviously) still using .sln and .csproj to hold his files together for VS - and can build via VS if needed - but actually does his build via the Nant .build files, executed via .bat.

This other post (also from Scott Hanselman) shows how you can execute external tools (such as MSBuild or a .bat file) from within Visual Studio. So I've created a build.bat file that looks like:

@echo off
echo Building %1 solution from build.bat
echo Directory: %~p1
C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe %~f1 %2

(I got the funky ~p and ~f parameter modifiers from here; %~f1 expands the MySolution.sln to the fully qualified path of the sln) ;-)

I've then set up the Visual Studio "External Tools" dialog so that: - command is "build.bat" - arguments is "$(SolutionFileName) /v:m" - initial directory is "&(SolutionDir)"

And I then added a button to the toolbar to execute it. I can go further to map the F5 key to run this, rather than the standard Visual Studio build.

Anyway, these are just some ideas (admittedly from someone else's brain!) but it gives me more insight into builds and how they can be done. There are some limitations (such as the errors won't appear in the Error List Window), but I'm sure this can be overcome if required.

I'm going to give this a go and see what I can achieve on MSBuild alone, and then also try hooking up to Hudson and see what cooks! :-)

By the way, if anyone is still reading at this point and has an opinion on whether the stuff I've presented in my own answer is good/bad/right/wrong/overkill/obsolete/flawed/whatever, please feel free to pitch in with your opinion.

Nice one, Pete.