If you walked into my office at a random moment during the day, chances are that you'd find one of my machines in the middle of a Windows Vista installation. As most people know, we produce daily internal test builds (actually, probably more like 20-30 builds when you count all the various private feature branches, but I digress), and I like to keep a couple of my machines up-to-date with a fairly fresh build, to track what's new and whether any bugs I've filed have been fixed. Mostly I install clean each time to prevent any left-over cruft from one daily build causing problems with the next build.
Anyway, there are times when I have a fresh machine and I just want to run some WPF code or a demo. It would be a real pain to have to install Visual Studio, the Windows SDK and the Visual Studio Extensions for WinFX every time just to compile something. Fortunately, you don't have to do that at all.
It's easy to forget that Windows Vista includes almost everything you need out the box to compile a solution from scratch: the C# and VB.NET command-line compilers as well as MSBuild - the command-line version of the build engine that we ship with Visual Studio. They're all in the standard .NET Framework directory: %windir%\Microsoft.NET\Framework\v2.0.50727.
You'll even find the assemblies necessary to compile XAML into BAML, here: %ProgramFiles\Reference Assemblies\Microsoft\WinFx\v3.0
The only thing some projects need is the assembly linker (al.exe) which you can install with just the .NET Framework 2.0 SDK (as opposed to the entire tools package). I've not spent any time to investigate what triggers the need for al.exe - presumably something like compiling satellite resource assemblies.
All you have to do is add the .NET Framework directory above to your path with the following line: set path=%path%;%windir%\Microsoft.NET\Framework\v2.0.50727and then you should be good to go with a command line such as the following: msbuild MediaMania.sln
I like this - it's saved me hours, and hopefully it'll save you some time too!
I recently faced the design challenge of getting an application and gadget to communicate. How to solve
Once I got WCF working in a gadget, another scenario came up: wouldn't it be nice if the gadget and the