Announcing the MSBuild Toolkit for Visual Studio 2005 RC!

This download has been removed. A new one will be posted in April 2006.

The MSBuild Toolkit for Visual Studio 2005 RC is the long-awaited successor to the MSBuild Compatibility Toolkit that I released late last year. Thanks to the work of Jomo Fisher, Mark Michaelis, and others, I've been able to put together a toolset that delivers on what I wanted to do since I first saw MSBuild at the Whidbey Alpha Design Review two years ago.

What Is It?
The MSBuild Toolkit for Visual Studio 2005 RC consists of two distinct parts:

  1. Drastically improved .TARGETS files for compiling MSBuild-based projects to .NET 1.1 and 1.0.
  2. A Visual Studio 2005 add-in that helps you manage the .TARGETS files your projects are referencing.

Lets take a look at these parts in depth.

Improved .TARGETS Files
After I released the first toolkit (based on the work of Jomo Fisher), Mark Michaelis and others led the charge to improve support for other runtimes through the underlying build engine. When .NET 2.0 Beta 2 was released, Jomo released the result of that work in a sample .TARGETS file that allowed C# projects to compile to .NET 1.1. This version allowed you to add other frameworks as options in the "Build Configuration" dialog. This is really powerful, as it allows you to compile to different frameworks individually, and batch build to all supported versions later on.

These new targets are significantly smaller than their predecessors, and far less brittle. They now handle non-Framework assembly references really well, and the whole system is practically seamless. It's really slick, and Jomo did a great job of laying the foundation for this project.

Besides support for Visual Basic and .NET 1.0 (which I added, and is included in this release), I still felt that a crucial portion of UI was missing...

Configuring Project Targets
Even with all this functionality, Visual Studio was still missing a way to manipulate the Project file (to change it's tags) without leaving the IDE. So I wrote an add-in that takes care of that for you. It gives you a UI similar to your project assembly references, and lets you select from the available targets installed on the system. You can see that UI below.


Figure 1: Managing Imported Targets

You can access this functionality from either of the following menu commands:

 
Figure 2: Assessing the Configuration Dialog

Why Did I Put This Together?
Visual Studio 2005 is an extremely compelling development environment. After using it so much in the Alpha and Beta 1, the thought of developing new Community Server add-ons in VS.NET 2003 was really disheartening. This package has allowed me to develop a ton of new code for LonghornBlogs.com using the Class Designer, Code Snippets, and Refactoring, while compiling for .NET 1.1 (because CS 1.0 was not compatible with ASP.NET 2.0).

Also, while Interscape has stopped building ASP.NET components for now, we might re-enter the market in the near future. One of the most time-consuming parts of the development cycle was maintaining two project files in two different IDEs that share the same source code files. This problem was one of the driving forces in giving our component business a break, and now supporting older versions of the Framework is much more feasible.

What's Still Missing?
While the add-in works, I'm not really happy with it at all. The whole process for building an add-in is TERRIBLE (Note to the VS Core Team: HIRE JAMIE CANSDALE!!!) and not for the faint of heart. I haven't been able to figure out how to remove commands on uninstall, so for now that part will be buggy.

Ultimately, I'd like the form for the add-in to either a) appear as a tab on the Project Properties form, or b) dock in the Document pane like the Project Properties form. I've forwarded the code for the Toolkit to the MSBuild team and the Group Product Manager for VS Core, so hopefully this kit will find it's way into VS2005, either as a "VB Refactor"-type addon, or a part of the code product. Whether or not you compile to older versions of the Framework, I think the ability to configure your Project Targets is extremely important, and maybe this will kickstart the team into making it into VS2005 RTM.

The TARGETS files, on the other hand, I'm pretty satisfied with. They work in all my scenarios. Hopefully they'll work in yours too.

Getting Support
I want to make this Toolkit better. So if you have any issues, list them here in my commants or e-mail me thru my contact page, and I'll get them fixed ASAP.

Downloading the Release Candidate
Download version 2.0.50602 here.

Thanks to everyone who made this possible. Hope it is of use you guys.

15 Comments

  • Thank you so much!!! This is incredibly valuable.

  • Thanks Robert, I can't wait to try it. If this thing works as expected you've just done ISV's a great service!!

  • :) Please do not hesitate to give me feedback. I'd like to get this thing rock solid so that ISVs and other companies can really depend on it for compatibility.

  • hey! great news!



    Can you tell me if there is a way to build .NET 1.1 web applications by using MSBuild or this tool? (without creating VS 2005 project for that 1.1 app, because it will not be possible to keep that project (VS 2005) and VS2003 project in sync.

  • Alex... I don't understand the question. You need to have an MSBuild project to be able to build with this tool. The easiest way is to upgrade your VS2003 project to VS2005 and use it to build your app.

  • Great tool!

    exactly what i was looking for.

    Thanks.



    I managed to get the vc2005 freeze when trying to access the "MSBuild Configuration" addin from the "Build" menu (rather from the context menu).

    It happens only when the project in the Solution explorer is not in focus.

  • Great, we are trying it right now.

    Thanks Robert!

  • Hi Robert,

    One problem we encounter with MSBuild Toolkit is referencing COM objects. VS2005 create RCW which is referencing mscorelib.dll version 2.0.0. Attempt to compile project for .NET 1.1 fails. The only temporary workaround we found is create wrapper in VS2003 and reference it in VS2005 as regular .NET assembly. Do you have any better idea?

  • Robert wrote:

    "Alex... I don't understand the question. You need to have an MSBuild project to be able to build with this tool. The easiest way is to ----> upgrade your VS2003 project <------ to VS2005 and use it to build your app".



    That's the point, I can not convert VS2003 projects to VS2005. Managers will not accept that risk. So I want to avoid using NAnt for 2003 projects and use MSBuild for both VS2003 and VS2005 projects.

  • Leon: Thanks. I haven't seen this yet, but I'm looking into how we should be doing it for teh targets/add-in.



    Alex: Sorry. This tool will not support that scenario. You can't use MSBuild on VS2003 projects.

  • Let me take that last comment back... I hadn't as of yet changed the platform.



    Again... This Rocks!

    Thanks

  • Did you read the readme at the end of the installer? Probably not, huh? The readme file has some basic information on how to get started. Please read it completely before using the toolkit. There will be a help file in the next release.

  • hi



    i installed the addin to a deferent directory the the setup sujested (same but on drive d)



    whe i started devenv it raised an exception.



    i solved the problem by re installing to the default directory - just thought you should know

  • Re: Building VS2003 projects that you don't want to convert to MSBuild format ...

    There is an assembly that ships with MSBuild called Microsoft.Build.Conversion.dll that it should be possible to use to convert the VS2003 projects to MSBuild projects on the fly. This contains the code that VS itself uses to do the upgrade, and I suppose in theory you could use it to convert every time just before you build, then throw away the converted projects when you're done building.

  • Yeah, but the problem is, you can't open a 2003 project in 2005 without converting. So we're talking about a command-line issue then, or as part of an automated build system. In that case, it is conceivable that it would work... but i don't see why you couldn't just convert to 2005 and compile to 2003, as that was the original intention of the kit.

Comments have been disabled for this content.