Note: This article is about targetting CLR version 1.1 with Whidbey Beta1. If you’re interested in Beta2 see this article.
Jomo Fisher–MSBuild doesn’t ship with a way to target CLR version 1.1. I discussed the reasons for this in a prior blog entry and I even said that I respected the decision given our resource limitations. On the other hand, respecting something and living with it is not the same thing so I decided to see exactly what it would take to target an older CLR.
My criteria were modest:
– I want reuse most of the existing build logic that ships with MSBuild. After all, this blog is about hacking the build, and throwing everything away and starting over didn’t seem in the spirit of things. (Plus it would be hard and I’m lazy).
– I wanted to build both Whidbey and CLR 1.1 binaries at the same time (in the same build gesture).
– I wanted to be able to compile at least minimal console applications, window applications and libraries.
– I wanted to keep Intellisense working and reflecting latest Whidbey libraries.
– I wanted to be able to call library code in other projects in the solution.
– I was willing to live with only C# support (at least for now).
– I didn’t care too much about optimal rebuild or clean support (at least for now).
What I ended up is a .targets file that meets my goals and that you can use as a sample for how to target multiple platforms with MSBuild. Here are the steps for Whidbey Beta 1:
(1) Copy this sample into a file called C:\MyTargets\CSharp.SideBySide.Targets
(2) Create a new C# console application called MyApp.
(3) Build and see that there are no errors or warnings.
(4) Open up MyApp.csproj in notepad and replace the import tag near the bottom with,
<Import Project=” C:\MyTargets\CSharp.SideBySide.Targets” />
(5) Save and exit from notepad.
(6) Return to VS and press “Reload” when prompted.
(7) Now “Rebuild” the console application.
At this point, if the build fails with a message like,
Properties\Settings.cs(13,9): error CS1518: Expected class, delegate, enum, interface, or struct
Then it’s working. This error is because the CLR 1.1 C# compiler doesn’t support partial classes. To get past this, you’ll need to delete the Settings.cs file. In the Solution Explorer click “Show All Files”. Now, in the Solution explorer you should see an entry called Settings.settings. Delete it and rebuild the project again.
At this point, the build should fail again with a message like,
Program.cs(4,26): error CS0234: The type or namespace name ‘Generic’ does not exist in the class or namespace ‘System.Collections’ (are you missing an assembly reference?)
This is because the old compiler didn’t support generics. You’ll need to delete this line,
from Program.cs and then build again. (As you can see, there are plenty of neat new features in the new compiler that you won’t be able to use if you want to target the older framework.)
This latest build should succeed, and you should now have a bin directory that looks like this (in part):
The first is the plain old Whidbey application. The second is a version that will run under the CLR version 1.1.
Please keep in mind that only the very basic scenarios have a chance of working. For example, I’m pretty confident that COM references are completely broken. If you try these targets out, let me know what you have problems with. If I can see a cheap, hack-the-build-worthy solution I’ll update the sample as I have the time.
Whidbey still won’t ship with a way to target the 1.1 CLR but at least now there’s starting point for doing it yourself.
In future entries, I will take apart the sample and explain how the various
hacks pieces work.
[Update December 16, 2004 –Jomo Fisher
Check out another community effort to target the 1.1 FX.
[Update October 8, 2004 —Jomo Fisher
It looks like there’s a chance that target names with dots in them will be illegal starting with Beta2. I’ve updated the sample, but if you’re using the prior version, you may want to get the latest to avoid being broken down the road.]
[Update October 5, 2004 —Jomo Fisher
Looks like there’s a similar effort going on at Test Driven .NET. This one actually creates a replacement for MSBuild.exe. Very cool. Here’s the link:
[Update October 3, 2004 —Jomo Fisher
What a difference a day makes. Robert McClaws saw my Hack the Build: Targetting .NET Runtime 1.1 Step-by-Step article from Friday and identified several ways to make it better. He wanted to target the 1.0 CLR, he wanted VB support, he wanted more flexible choices over where outputs go. In other words, he wanted the build that *he* wanted, and that’s what MSBuild is all about.
From his posting,
“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.”
I haven’t looked at his stuff, but it looks like it has a nice installer MSI and (if my reading of his post is correct) he’s made templates for creating new projects.
You can check his stuff out here.]
This posting is provided “AS IS” with no warranties, and confers no rights.