Robert McLaws: FunWithCoding.NET

Public Shared Function BrainDump(ByVal dotNet As String) As [Value]

News

<script type="text/javascript"><!-- google_ad_client = "pub-4330602465258980"; google_hints = "ASP.NET, VB.NET, C#, C#.NET, WindowsForms, .NET Framework, VS2005, Visual Studio, XAML, WinFX, Windows Workflow, WPF, WCF, Atlas, NetFX3, Visual Studio Orcas"; google_ad_width = 120; google_ad_height = 240; google_ad_format = "120x240_as"; google_ad_type = "text_image"; google_ad_channel ="4997399242"; google_color_border = "B6C9E7"; google_color_bg = "EFEFEF"; google_color_link = "0000FF"; google_color_text = "000000"; google_color_url = "002C99"; //--></script> <script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script>
<!--
-->

You should feel free to challenge me, disagree with me, or tell me I'm completely nuts in the comments section of each blog entry, but I reserve the right to delete any comment for any reason whatsoever. That said, I will most likely only delete abusive, profane, rude, or annonymous comments, so keep it polite, please.

Blogroll

Cool .NET Articles

My .NET Tools

My Builder.com Articles

My MSKB Articles

Announcing the MSBuild Compatibility Toolkit 1.0

This is a long post, so I'll give an intro at the top. I've created a simple system for supporting all versions of the .NET Framework from VS2005. Click through to keep reading about the process, and download the redistributable.

I saw the functionality of MSBuild over a year ago at the PDC, and ever since then I have been chomping at the bit for a unified build solution for Interscape's components. You see, when I release a component, I want to make sure that we have a compiled version targeted at each version of the .NET Framework. Up to this point, it's been a 3.2GB pain in the ass, because I have to have VS.NET 2002 and VS.NET 2003 installed side by side. I have to maintain 2 different sets of project and solution files..... it's just ridiculous.

So a friend of mine e-mailed me Jomo Fisher's entry about targeting .NET 1.1 with MSBuild, and I was very excited. After investigating it a bit, I found it to be less that desirable, for several reasons:

  • Too much hard-coding: I wanted the targets to build based on the configuration settings in the project. Jomo's target file had the folder hierarchy hard-coded.
  • Build folders didn't make sense: Following on the heels of the last problem, I didn't like the setup for the build directories. I wanted a hierarchal structure that I could use to create per-product build folders that had a predictable layout for my installer projects.
  • Conditional constants: Since I already use conditional compilation constants, I needed to bring the one's in Jomo's target file in line with my system.
  • Hacky file locations & names: Jomo wanted to put the files in a "Targets" folder, and hard-code more file locations into the system. I wanted a consistent, dynamic naming structure for the files, and to drop them in the .NET 2.0 install directory with the rest of the Targets.
  • Only for C#: Most of my code is in VB. So I needed to be able to use the Vbc target, which required some digging into MSBuild with Reflector.
  • Only for 1.1: My main concern is compiling to .NET 1.1 and .NET 1.0 simultaneously... .NET 2.0 is really just an afterthought at this point, since we are not allowed to release components for it yet.
  • Requires editing project files: I wanted to be able to create compatible projects from scratch, so I could just get up and go without any effort.

So I spent the past 24 hours (practically straight) working on making everything work the way I wanted. The result is the MSBuild Compatibility Toolkit, a clean, standardized system for extending .NET Framework compilation support, with or without Visual Studio 2005. It features:

  • Support for Visual Basic and Visual C#
  • Support for .NET 1.1 (Everett) and .NET 1.0 (Ranier)
  • Standardized target files that conform to Microsoft's naming structure (Microsoft.VisualBasic.Everett.Targets, etc.)
  • Cleaner, dynamic target files
  • Creates an intuitive build directory structure
  • Clean, straightforward conditional compilation constants
  • Custom Visual Studio 2005 Project templates that include out-of-the-box compatibility support.

So, along with those features, I had a couple of goals in mind. I wanted to be able to demonstrate in a clean, effective manner how simple it was to customize the build system, and I wanted to also show how to create custom templates for VS2005. I found out that, after a bit of digging, that it is super easy to create templates that you can beef up with a ton of pre-defined code. If you need to enforce standards in project naming, assembly references, or versioning... customizable templates are the way to go.

The templates I added are VB and C# templates for creating different types of compatible web controls. I could have gone all out and created new templates for every project type.... but I figured if you needed a special one, you could use my templates as an example for modifying your own. After the installer runs, you find them in the "My Projects" section at the bottom of the project list.

Ok, enough talk. Be sure to read the note at the end of the installer, it has some very important points to note. And this isn't an Interscape product, it's just something that I wanted to make available to everyone. Feel free to modify the files as you see fit. If you make any major improvements, please email me so that I can put them into a future version.

Download MSBuild Compatibility Toolkit 1.0 now.

Posted: Oct 03 2004, 10:20 AM by interscape | with 10 comment(s)
Filed under:

Comments

Jose Cruz said:

This works in Visual C# Express?
# October 9, 2004 7:32 PM

Robert McLaws said:

It should work with ALL versions of VS2005, including the Express SKUs.
# October 9, 2004 7:38 PM

Alenas said:

The problem is that your targets do not set external references (not a framework ones).
Also in release build it complains about /errorreport:none
# October 17, 2004 6:43 PM

Alenas said:

I made mistake - i was referencing 2.0 assembly that's why it was not included in references.
# October 17, 2004 7:09 PM

Alenas said:

f@(% - anyway it did not set reference even with 1.1 assembly.
# October 17, 2004 7:17 PM

Robert McLaws said:

Yes, I'm aware that it does not resolve non-Framework references, and that was very specifically discussed in the release notes. I'm working on a solution.
# October 18, 2004 2:55 AM