Jomo Fisher -- Sharp Things : MSBuild

Programmatically Resolve Assembly Name to Full Path the Same Way MSBuild Does

Jomo Fisher — Fri, 23 May 2008 00:59:00 GMT

Jomo Fisher—Every once in a while I find I need to turn and assembly name like “System” or “System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL” into a path to the actual file for that assembly. This is a tricky problem considering the assembly name might be for a product install in Program Files or elsewhere. MSBuild already has rules for doing this resolution. Here’s how to call that code directly (written in F#):

#light

#r "c:\Windows\Microsoft.NET\Framework\v2.0.50727\Microsoft.Build.Tasks.dll"

#r "c:\Windows\Microsoft.NET\Framework\v2.0.50727\Microsoft.Build.Utilities.dll"

#r "c:\Windows\Microsoft.NET\Framework\v2.0.50727\Microsoft.Build.Framework.dll"

#r "c:\Windows\Microsoft.NET\Framework\v2.0.50727\Microsoft.Build.Engine.dll"

open Microsoft.Build.Tasks

open Microsoft.Build.Utilities

open Microsoft.Build.Framework

open Microsoft.Build.BuildEngine

/// Reference resolution results. All paths are fully qualified.

type ResolutionResults = {

/// Paths to primary references

referencePaths:string array

/// Paths to dependencies

referenceDependencyPaths:string array

/// Paths to related files (like .xml and .pdb)

relatedPaths:string array

/// Paths to satellite assemblies used for localization.

referenceSatellitePaths:string array

/// Additional files required to support multi-file assemblies.

referenceScatterPaths:string array

/// Paths to files that reference resolution recommend be copied to the local directory

referenceCopyLocalPaths:string array

/// Binding redirects that reference resolution recommends for the app.config file.

suggestedBindingRedirects:string array

}

let Resolve(references:string array, outputDirectory:string) =

let x = { new IBuildEngine with

member be.BuildProjectFile(projectFileName, targetNames, globalProperties, argetOutputs) = true

member be.LogCustomEvent(e) = ()

member be.LogErrorEvent(e) = ()

member be.LogMessageEvent(e) = ()

member be.LogWarningEvent(e) = ()

member be.ColumnNumberOfTaskNode with get() = 1

member be.ContinueOnError with get() = true

member be.LineNumberOfTaskNode with get() = 1

member be.ProjectFileOfTaskNode with get() = "" }

let rar = new ResolveAssemblyReference()

rar.BuildEngine <- x

rar.TargetFrameworkDirectories <- [|@"C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5\"|]

rar.AllowedRelatedFileExtensions <- [| ".pdb"; ".xml"; ".optdata" |]

rar.FindRelatedFiles <- true

rar.Assemblies <- [|for r in references -> new Microsoft.Build.Utilities.TaskItem(r):>ITaskItem|]

rar.SearchPaths <- [| "{CandidateAssemblyFiles}"

"{HintPathFromItem}"

"{TargetFrameworkDirectory}"

"{Registry:Software\Microsoft\.NetFramework,v3.5,AssemblyFoldersEx}"

"{AssemblyFolders}"

"{GAC}"

"{RawFileName}"

outputDirectory |]

rar.AllowedAssemblyExtensions <- [| ".exe"; ".dll" |]

rar.TargetProcessorArchitecture <- "x86"

if not (rar.Execute()) then

failwith "Could not resolve"

{

referencePaths = [| for p in rar.ResolvedFiles -> p.ItemSpec |]

referenceDependencyPaths = [| for p in rar.ResolvedDependencyFiles -> p.ItemSpec |]

relatedPaths = [| for p in rar.RelatedFiles -> p.ItemSpec |]

referenceSatellitePaths = [| for p in rar.SatelliteFiles -> p.ItemSpec |]

referenceScatterPaths = [| for p in rar.ScatterFiles -> p.ItemSpec |]

referenceCopyLocalPaths = [| for p in rar.CopyLocalFiles -> p.ItemSpec |]

suggestedBindingRedirects = [| for p in rar.SuggestedRedirects -> p.ItemSpec |]

}

try

let s = Resolve([| "System"

"System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL"

"Microsoft.SqlServer.Replication"

|], "")

printfn "%A" s

finally

ignore (System.Console.ReadKey())

The result of running the code looks like this:

{referencePaths =

[|"C:\\Program Files\\Microsoft SQL Server\\90\\SDK\\Assemblies\\Microsoft.SqlServer.Replication.dll";

"C:\\Program Files\\Reference Assemblies\\Microsoft\\Framework\\v3.5\\System.Core.dll";

"C:\\Windows\\assembly\\GAC_MSIL\\System\\2.0.0.0__b77a5c561934e089\\System.dll"|];

referenceDependencyPaths =

[|"C:\\Windows\\assembly\\GAC_MSIL\\System.DirectoryServices\\2.0.0.0__b03f5f7f11d50a3a\\System.DirectoryServices.dll";

"C:\\Windows\\assembly\\GAC_MSIL\\System.Xml\\2.0.0.0__b77a5c561934e089\\System.Xml.dll";

"C:\\Windows\\assembly\\GAC_32\\Microsoft.SqlServer.BatchParser\\9.0.242.0__89845dcd8080cc91\\Microsoft.SqlServer.BatchParser.dll";

"C:\\Windows\\assembly\\GAC_MSIL\\System.Runtime.Remoting\\2.0.0.0__b77a5c561934e089\\System.Runtime.Remoting.dll";

"C:\\Windows\\assembly\\GAC_MSIL\\Microsoft.Vsa\\8.0.0.0__b03f5f7f11d50a3a\\Microsoft.Vsa.dll";

"C:\\Windows\\assembly\\GAC_32\\System.Data.OracleClient\\2.0.0.0__b77a5c561934e089\\System.Data.OracleClient.dll";

"C:\\Program Files\\Microsoft SQL Server\\90\\SDK\\Assemblies\\Microsoft.SqlServer.ConnectionInfo.dll";

"C:\\Windows\\assembly\\GAC_MSIL\\Accessibility\\2.0.0.0__b03f5f7f11d50a3a\\Accessibility.dll";

"C:\\Windows\\assembly\\GAC_32\\System.Transactions\\2.0.0.0__b77a5c561934e089\\System.Transactions.dll";

"C:\\Windows\\assembly\\GAC_MSIL\\System.DirectoryServices.Protocols\\2.0.0.0__b03f5f7f11d50a3a\\System.DirectoryServices.Protocols.dll";

"C:\\Windows\\assembly\\GAC_MSIL\\System.Drawing\\2.0.0.0__b03f5f7f11d50a3a\\System.Drawing.dll";

"C:\\Windows\\assembly\\GAC_MSIL\\System.Deployment\\2.0.0.0__b03f5f7f11d50a3a\\System.Deployment.dll";

"C:\\Program Files\\Microsoft SQL Server\\90\\SDK\\Assemblies\\Microsoft.SqlServer.Smo.dll";

"C:\\Windows\\assembly\\GAC_32\\System.EnterpriseServices\\2.0.0.0__b03f5f7f11d50a3a\\System.EnterpriseServices.dll";

"C:\\Windows\\assembly\\GAC_MSIL\\System.Web.RegularExpressions\\2.0.0.0__b03f5f7f11d50a3a\\System.Web.RegularExpressions.dll";

"C:\\Program Files\\Microsoft SQL Server\\90\\SDK\\Assemblies\\Microsoft.SqlServer.WmiEnum.dll";

"C:\\Program Files\\Microsoft SQL Server\\90\\SDK\\Assemblies\\Microsoft.SqlServer.ServiceBrokerEnum.dll";

"C:\\Windows\\assembly\\GAC_MSIL\\System.Configuration\\2.0.0.0__b03f5f7f11d50a3a\\System.Configuration.dll";

"C:\\Windows\\assembly\\GAC_MSIL\\System.Web.Services\\2.0.0.0__b03f5f7f11d50a3a\\System.Web.Services.dll";

"C:\\Windows\\assembly\\GAC_MSIL\\System.Management\\2.0.0.0__b03f5f7f11d50a3a\\System.Management.dll";

"C:\\Windows\\assembly\\GAC_MSIL\\System.Design\\2.0.0.0__b03f5f7f11d50a3a\\System.Design.dll";

"C:\\Windows\\assembly\\GAC_32\\System.Web\\2.0.0.0__b03f5f7f11d50a3a\\System.Web.dll";

"C:\\Windows\\assembly\\GAC_MSIL\\System.Windows.Forms\\2.0.0.0__b77a5c561934e089\\System.Windows.Forms.dll";

"C:\\Windows\\assembly\\GAC_MSIL\\System.Security\\2.0.0.0__b03f5f7f11d50a3a\\System.Security.dll";

"C:\\Program Files\\Microsoft SQL Server\\90\\SDK\\Assemblies\\Microsoft.SqlServer.SmoEnum.dll";

"C:\\Windows\\assembly\\GAC_MSIL\\System.Runtime.Serialization.Formatters.Soap\\2.0.0.0__b03f5f7f11d50a3a\\System.Runtime.Serialization.Formatters.Soap.dll";

"C:\\Windows\\assembly\\GAC_MSIL\\Microsoft.JScript\\8.0.0.0__b03f5f7f11d50a3a\\Microsoft.JScript.dll";

"C:\\Windows\\assembly\\GAC_MSIL\\System.Configuration.Install\\2.0.0.0__b03f5f7f11d50a3a\\System.Configuration.Install.dll";

"C:\\Windows\\assembly\\GAC_MSIL\\Microsoft.VisualC\\8.0.0.0__b03f5f7f11d50a3a\\Microsoft.VisualC.dll";

"C:\\Program Files\\Microsoft SQL Server\\90\\SDK\\Assemblies\\Microsoft.SqlServer.SqlEnum.dll";

"C:\\Windows\\assembly\\GAC_32\\System.Data\\2.0.0.0__b77a5c561934e089\\System.Data.dll";

"C:\\Windows\\assembly\\GAC_MSIL\\System.Drawing.Design\\2.0.0.0__b03f5f7f11d50a3a\\System.Drawing.Design.dll";

"C:\\Program Files\\Microsoft SQL Server\\90\\SDK\\Assemblies\\Microsoft.SqlServer.Rmo.dll";

"C:\\Windows\\assembly\\GAC_MSIL\\System.Data.SqlXml\\2.0.0.0__b77a5c561934e089\\System.Data.SqlXml.dll";

"C:\\Windows\\assembly\\GAC_MSIL\\System.ServiceProcess\\2.0.0.0__b03f5f7f11d50a3a\\System.ServiceProcess.dll";

"C:\\Program Files\\Microsoft SQL Server\\90\\SDK\\Assemblies\\Microsoft.SqlServer.RegSvrEnum.dll"|];

relatedPaths = [||];

referenceSatellitePaths = [||];

referenceScatterPaths =

[|"C:\\Windows\\assembly\\GAC_32\\System.EnterpriseServices\\2.0.0.0__b03f5f7f11d50a3a\\System.EnterpriseServices.Wrapper.dll"|];

referenceCopyLocalPaths = [||];

suggestedBindingRedirects = [||];}

This posting is provided "AS IS" with no warranties, and confers no rights.

Hack the Build: Use ILMerge and MSBuild to Combine Multiple Assemblies into One

Jomo Fisher — Mon, 06 Mar 2006 01:13:00 GMT

Jomo Fisher--Over the last few years I've been coding mostly in C#--before that, my day-to-day work was done in C++. I don't miss much about C++, but one of the things that I do miss is the ability to link many .LIB files into a single DLL or EXE

I've known that it was possible to do this in .NET (with LINK.EXE or ILMERGE.EXE) but there is no built-ine support in VS2005 for doing this.

This weekend, I decide to see what it would take to plug ILMERGE into the regular C# build system. It's pretty simple to get basic support.

(1) Download and install ILMerge MSI: http://www.microsoft.com/downloads/details.aspx?FamilyID=22914587-b4ad-4eae-87cf-b14ae6a939b0&displaylang=en

(2) Save the this file to C:\Program Files\msbuild\Ilmerge.CSharp.targets

(3) In VS2005, right-click on the projectin solution explorer and select "Unload Project"

(4) Right-click again and pick 'Edit MyApp.csproj'

(5) Replace the <Import> line with <Import Project="$(MSBuildExtensionsPath)\Ilmerge.CSharp.targets" /> and save.

(6) Right-click again on the project in solution explorer and select "Load Project"

(7) Build.

Now, the project you modified will automatically have all referenced assemblies merged-in. Only the assemblies marked "Copy Local" will be merged so system assemblies and GAC assemblies won't be merged by default.

You only need to modify the projects you would like to have merging. In other words, you can have mixed merged and unmerged projects in the same solution.

This posting is provided "AS IS" with no warranties, and confers no rights.

Update: Targetting 1.1 .NET Framework with MSBuild

Jomo Fisher — Wed, 16 Nov 2005 00:07:00 GMT

A while back I post a sample that shows you how to target the 1.1 framework with MSBuild.

Now, another team within Microsoft is working on turning it into a more polished add-on for VS 2005:

http://blogs.msdn.com/msbuild/archive/2005/11/09/490817.aspx

I've chatted with many of you on my blog and I think I know some of your top requests for such product: Make it work with Express versions of VS; make it work for VB .NET; make COM references work; do some hard-core testing on it :)

If you’ve used these targets and wished they did something a little differently let me know on this blog.

Have you seen a bug? I’d love to hear about those too so we can be sure to get them fixed.

This posting is provided "AS IS" with no warranties, and confers no rights.

How to plug your own C# compiler into VS 2005.

Jomo Fisher — Thu, 01 Sep 2005 00:09:00 GMT

Jomo Fisher--A bunch of future C# compiler features (think 3.0 and beyond) will be on display at PDC in a couple of weeks. We wanted to ship a nice installation that lets people try out the new features of the compiler while still leaving VS 2005 working for regular 2005 C# projects. MSBuild made this insanely easy.

I wasn't going to post the technical details because, really, how many people need to plug in a replacement for the C# compiler? Well, this guy does: http://channel9.msdn.com/ShowPost.aspx?PostID=107239#107239. So I think I'll talk about it a little bit in case other people are interested.

Here are the steps to replace the C# compiler for a single project. This assumes the your compiler is called CSC.EXE and is switch-compatible with CSC.EXE from VS 2005.

(1) Create a plain old C# project.

(2) Edit the .CSPROJ file with notepad and replace the <Import ...> line with

(3) Create "c:\MySubfolder\MyTargets.targets" and put this in there:

<Project

DefaultTargets="Build"

xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

<CscToolPath>c:\MySubfolder\</CscToolPath>

<UseHostCompilerIfAvailable>false</UseHostCompilerIfAvailable>

</PropertyGroup>

</Project>

(4) Save everything.

(5) Put your replacement CSC.EXE in c:\MySubfolder

That's it. You can load up your project and build with your own compiler. One big caveat is that you'll still get the regular C# 2.0 IntelliSense(tm) when editing in VS.

Make it into a Project Template

Once you have the project building. You can make it into a project template by going to File\Export Template... in VS 2005.

This posting is provided "AS IS" with no warranties, and confers no rights.

Hack the Build: Use the Whole Test-First Whale

Jomo Fisher — Wed, 25 May 2005 19:51:00 GMT

Jomo Fisher—

Try lots of things to improve quality. Keep doing what works, stop doing what doesn’t.

Writing code with Test-Driven-Development (TDD) takes about 30% longer than writing code without it. This was my experience on MSBuild. Still, as I noted here and here, I’m a fan of TDD. Code quality tip #2 explains why…

Tip# 2: Take Maximum Advantage of Developer-Written Tests

Subsistence hunters use every part of their kill. This makes sense because it’s hard to catch a whale. If you expend that kind of effort, you need to maximize your return. If you don’t then you’ll freeze all winter while your neighbor down the coast is toasty warm next to their blubber-oil stove.

I don’t think of TDD as just a goal in itself. I think of it as a platform for a set of code-quality drivers. What follows is a set of ideas for how to get the maximum use out of your developer-written tests. We used all of these, with success, on MSBuild:

Everyone Shares the Tests—We checked the test source code into source control alongside the shipping production code. Everyone worked with and contributed to the same set of tests. As a developer, this allows you to create features that are virtually impossible for your well-intentioned team-mates to break.

You Can’t Check in until All the Tests Pass—In addition to using the GUI test driver for development, we have a single batch file that reports a failure if any tests are failing. Before you can check it, you have to pass the whole battery of tests. This keeps the code in source control pristine.

Drive Up Code Coverage—With ideal TDD you should be able to hit every line of code in your product with unittests. In practice, this turned out to be more like ~87% of the code for MSBuild. You can judge the relative health of your unittests (and your TDD process in general) by looking at code covered by the unittests. Try this: set a break point on every line in one source file, run your unittests under the debugger. Every time you hit a break point, remove it. When you’re done, the remaining break points indicate unittests that you’re missing.

Every Bug Has a Test—When fixing bugs, first create a test that fails. Then fix the bug and see the test pass. Bug regressions (bugs which return after they’ve supposedly been fixed) are very expensive. If you use a bug tracking system that assigns a number to every bug, consider sticking this number in the method name:



[Test]
public void Regress99999_EjectedCDInjuresUser() {...}

This way, you can always track the test back to the original bug that it was supposed to address.

Refactor Mercilessly—People sometimes use a word called “churn”. It’s a derogatory term for changing a lot of code at once. Thing is, changing a lot of code is often the right answer. Avoiding a needed refactoring can cost you more down the road. Once you have a good corpus of unittests, take advantage and refactor whenever it makes sense. If you’re a manager or team-lead, let your team know it’s OK to refactor as much as they need to.

Mutation Testing—Think of unittests as an immune system for your code. If there’s a bug in your code, then a test should fail. The idea behind mutation testing is to intentionally inject a bug in your code and then run unittests to make sure at least one fails. There are plenty of ways to create bugs in your code. For example, if you have this:

	
if (condition) {...}

Then replace it with,

	
if (condition && false) {...}

Did a test fail? If not, add a unittest that does fail. If you can’t, the code is probably redundant and can be removed.

We automated the process of systematically injecting bugs into the code and running unittests. Our solution used a hand-written C# parser to generate the mutation set. I haven’t tried it, but there’s a free tool called Nester which is supposed to automate this for you for C# files.

See Tip #1: Code Reviews

This posting is provided "AS IS" with no warranties, and confers no rights.

Hack the Build: An Introduction to MSBuild

Jomo Fisher — Mon, 02 May 2005 20:22:00 GMT

Mitch Denny gives an excellent introduction to MSBuild: http://notgartner.com/posts/1573.aspx

This posting is provided "AS IS" with no warranties, and confers no rights.

Hack the Build: Update to 1.1 targets

Jomo Fisher — Wed, 27 Apr 2005 20:24:00 GMT

Jomo Fisher – Oren pointed out that the wrong resource compilation was being done in the 1.1 targets I posted. I've corrected the problem so you may want to take another snapshot of the targets files.

He also pointed out that, at debug time, the FX 2.0 versions of framework assemblies were being loaded, not the 1.1 versions. This may not bug people because the 2.0 FX is largely compatible with 1.1. If it does bug you, you can use debug with the "Start external program" action instead of the "Start project" action.

This posting is provided "AS IS" with no warranties, and confers no rights.

Hack the Build: Use Whidbey Beta2 to target .NET Runtime 1.1

Jomo Fisher — Fri, 22 Apr 2005 20:45:00 GMT

Jomo Fisher – A while back, I posted a sample that showed how to target the .NET 1.1 runtime (the version that came with Visual Studio .NET 2003 also known as Everett) with MSBuild. Now Beta 2 has rolled around and I can see that there have been enough changes to MSBuild to warrant an entire rewrite of that original sample.

I’ll get into the details of how it all works down below, but right now let’s just get it working on your machine. Here are the steps:

(1)   Copy this MSBuild targets file to “C:\program files\msbuild\CrossCompile.CSharp.targets”

(2)   Create a new C# project somewhere called MyApp.

(3)   Use notepad to edit MyApp.csproj. Replace the entire <Import> tag with

<Import Project="$(MSBuildExtensionsPath)\CrossCompile.CSharp.targets" />

(4)   When prompted, reload the project. You’ll have to answer a security dialog.

(5)   In VS, click the drop-down that says ‘Any CPU’ and select ‘Configuration Manager’

(6)   Under Active Solution Platform, select <New…>

(7)   Select ‘.NET 1.1’ (pretty cool, eh?) and press OK.

(8)   Build and notice error about System.Collections.Generic. This means its working because generics aren’t supported in 1.1.

(9)   Open Program.cs and delete the line:

using System.Collections.Generic;

     And rebuild.

That’s it, its working.

As with the last sample I posted on this, I expect that only basic scenarios will work here. If you run into a problem, drop me a note. If I see a quick solution I'll post it. Otherwise, I can still publish those limitations here so that other people can learn from your experience.

What’s New?

There are some differences between this version and the prior sample I published that show off some nice new features in MSBuild for Beta2:

This version shows how to add entirely new Platforms for VS to pick up. See the $(AvailablePlatforms) property in CrossCompile.CSharp.Targets. You could, pretty easily, add other targets from .NET 1.0 or any other tool that is roughly command-line interchangeable with CSC.EXE.
The reference resolution logic in this version is far more robust. Many more scenarios should work now, including references to third-party assemblies as well as project-to-project references. (Though you still can't reference 2.0-compiled assemblies into 1.1 projects--this is a limitation built into the CLR itself).
We’ve added a new built in property called $(MSBuildExtensionsPath) which is defined to be like “C:\Program Files\MSBuild”. This is a well-known spot where people can dump their custom targets files. This saves you from having to hard-code a path in your project or template.
Targets can now be entirely overridden. The GetFrameworkPaths targets from Microsoft.Common.Targets is overridden in CrossCompile.CSharp.Targets so that an alternate directory for target framework directory can be injected.
This version doesn’t build 2.0 and 1.1 at the same time. This is nicer, I think, because otherwise you see duplicate errors when you build.

Moving On

At the end of this month I'm moving from the MSBuild team (5th floor, building 41 in Redmond) to the C# team (1st floor, building 41 in Redmond). Working on MSBuild has been a blast and I intend to keep on blogging about it if I think I having something of value to say. After a while, I hope to have something useful to say about C# too. I think "Hack the Build" still fits, so I'll keep the name.

This posting is provided "AS IS" with no warranties, and confers no rights.

Hack the Build: Cracking MSBuild Project Files

Jomo Fisher — Wed, 09 Feb 2005 19:59:00 GMT

Jomo Fisher -- Here's how you can use the MSBuild Object Model to programmatically access the contents of a project file. This sample console application accepts a single parameter--the full path to some MSBuild project file--and displays all of the assemblies that project references:

using System;

using System.IO;

using Microsoft.Build.BuildEngine;

class MSBuildCracker

{

const string msbuildBin

= @"C:\WINDOWS\Microsoft.NET\Framework\v2.0.40607";

static void Main(string[] args)

{

//Load the project.

Engine engine = new Engine(msbuildBin);

Project project = new Project(engine);

project.LoadFromFile(args[0]);

// Get the references and print them.

ItemGroup references =

project.GetEvaluatedItemsByType("Reference");

foreach (Item item in references)

{

Console.WriteLine(item.Include);

}

Here's how you would call the tool:

MSBuildCracker c:\myprojects\project1\project1.csproj

And this is the result:

System
    System.Deployment
    System.Drawing
    System.Windows.Forms

You can use this technique to access any of the items (like Reference or Compile) or properties (like AssemblyName or Platform).

This posting is provided "AS IS" with no warranties, and confers no rights.

Hack the Build: Hide Items from Visual Studio Solution Explorer

Jomo Fisher — Tue, 25 Jan 2005 20:51:00 GMT

Jomo Fisher -- Custom MSBuild projects and targets files that you write typically have ItemGroups to contain lists of files. For example,

When you fire up VS with the above code in a project you'll find that "a.txt" shows up in the solution explorer. Depending on how you intend these items to be used you might be delighted by this or you might be annoyed. You'll be annoyed if the ItemGroup is a private implementation detail and should not be in the user's face.

If this has happened to you, try this:

<ItemGroup>
<MyFiles Include="a.txt">
<InProject>false</InProject>
</MyFiles>
</ItemGroup>

The InProject metadata will not affect the build at all. It just tells Visual Studio that you don't want the item displayed in Solution Explorer.

This posting is provided "AS IS" with no warranties, and confers no rights.

Hack the Build: Programmatically Converting Older VS .NET Projects to MSBuild

Jomo Fisher — Mon, 29 Nov 2004 20:42:00 GMT

Jomo Fisher--There are plenty of reasons you might want to programmatically convert projects from VS .NET 2003 format to MSBuild format. Maybe you have a bunch of old .csproj files and you'd like to convert them in batch. Maybe you'd like to keep your projects in VS7 format and convert them to MSBuild format on the fly. These are definitely Hack-the-Build-worthy pursuits, so let's dig in.

MSBuild ships with an assembly called Microsoft.Build.Conversion.dll which contains the code that Visual Studio .NET 2005 uses to convert older C# and VB projects into MSBuild format (unfortunately C++ is not supported).

The code for calling this API is so simple, I can paste it right here:

Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

Written by Jomo Fisher

using System;

using System.Text;

using Microsoft.Build.Conversion;

class ConvertProject

{

static void Main(string[] args)

{

ProjectFileConverter c =

new ProjectFileConverter();

c.OldProjectFile = args[0];

c.NewProjectFile = args[1];

c.Convert();

}

To invoke, just call the code with source and destination file names:

ConvertProject VS7.csproj VS8.csproj

A few things to note:

· You'll need to add a reference to Microsoft.Build.Conversion in your project.

· You'll need to manually copy the DLL Microsoft.Build.Conversion.dll into the same directory as the application built from the code above. Chances are that we'll have this DLL in the GAC for the next Beta, but for now you'll just need to manually copy it.

· This API is undocumented and not supported for calling directly. Caveat emptor, etc.

If you subscribe to other Microsoft Visual Studio related blogs you may have noticed a lull in the postings. This is because we're working like caffeinated woodpeckers getting the next Beta of VS ready. Thankfully, the tryptophan has cut through my (legal) stimulant haze long enough this morning to allow me to post a hack for you—I hope you find it worthy.

One thing worth mentioning as we head down the homestretch: We've used Test Driven Development with NUnit throughout most of the MSBuild development cycle. We're really seeing a big pay-off in the end-game--we're able to make difficult changes in complex code with confidence that we're not breaking functionality. In other words, I've tasted the Kool-Aid and can only say “Oh, Yeaahh!”.

This posting is provided "AS IS" with no warranties, and confers no rights.