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

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.