Alex Rivera | Logout

How to move onto automated builds with Visual Studio?

Asked 2009-08-21T21:15:48.070
9

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?

Edit
Report

3 Answers

6

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.

answered 2009-08-21T21:19:38.360
2

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.

answered 2009-08-21T21:23:33.000
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 answered 2009-08-23T20:11:41.963

Your Answer