I always forget this little nugget, so I'm going to dump it out here...


For those of you arriving late, MSBuild is the build engine for .NET 2.0 and above.  You'll find the executable in %windir%\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe.

To use MSBuild to build your assemblies, you'll need to write MSBuild script in the form of XML.  What's nice about Visual Studio, though, is that Visual Studio pretty much writes your MSBuild script for you as you code your project.  If you drop your project files (CSPROJ for C# projects) into Notepad, you'll see what I mean.

Now, we all know that projects are housed under a solution described by a SLN file and we typically build all our projects at once by building the solution.  So, it stands to reason that the SLN file is persisted as MSBuild script, too, right?  Wrong.  Just drop that sucker into Notepad--that's not MSBuild syntax...I don't know what that is!  So how can MSBuild build an entire solution from an SLN file that's not even MSBuild script?

The secret is that apparently MSBuild, on-the-fly, converts the SLN file to MSBuild script then runs that script to generate the necessary output.  By default, we never see this converted file; however there is a way to see it.  Follow these steps:

1. From the command line, type: set msbuildemitsolution=1
2. Now run MSBuild: msbuild Solution1.sln
3. Look in the directory of your SLN file and you'll find Solution1.sln.proj (a .cache file is also created which appears to be a copy of the .proj file)

Thanks to Sayed Ibrahim Hashimi for blogging about this.

The next question is, of course, should I generate one of these PROJ files first, then run MSBuild against that file to build the artifacts of my solution--particularly if I need to do some operations at the solution level before, during, or after the build?  The answer is: I'm not sure.  I recall seeing some posts from folks who did just this and got some unexpected behavior (try googling msbuildemitsolution).  So, I would think that the safest course of action would be to customize you MSBuild script (CSPROJ files) as much as you can first.  If you can't quite address all your needs at the project level--say, moving different reference files around or whatever--I might consider writing a batch file around the whole process to see if that can better address your requirements.