It's time to discuss how the ResolveComReference (RCR) task will work in MSBee, since I've already finished a prototype. Before delving into an explanation, however, let's recap the problem: When the standard RCR task runs in MSBuild, interop assemblies are generated as necessary. Since these assemblies are generated with .NET 2.0, build errors occur when they're referenced by .NET 1.1 tools, like csc or vbc.

To support COM references in MSBee, we need a way to generate .NET 1.1 compatible assemblies as well as resolve our COM references. After looking at some approaches, we knew that we didn’t want to rewrite the task ourselves as it is quite complicated. Since it doesn’t shell out to tlbimp or aximp, we can’t simply change the tool paths to generate compatible assemblies.

 

After further investigation, we concluded the easiest solution might be to rebuild the ResolveComReference task in .NET 1.1. If we can force the task to execute using .NET 1.1, it will generate .NET 1.1 interop assemblies that can be referenced by the .NET 1.1 compilers, thus solving our problem.

 

To accomplish this, we’ll need RCR to target .NET 1.1. This involves replacing all .NET 2.0 specific code with .NET 1.1 code. While this may sound trivial, due to the brevity of the previous sentence, it actually isn’t. Consider that the RCR task references the Microsoft.Build.Framework and Microsoft.Build.Utilities DLLs. Thus, for me to rebuild RCR for .NET 1.1, the DLLs it references must also be .NET 1.1 compatible. Therefore, I need to replace all .NET 2.0 specific code in all MSBuild classes that are directly or indirectly referenced by the RCR task.

 

The other key issue is how do I guarantee that the code will always execute against .NET 1.1? This is the easier problem since app.config files can enforce required runtimes. Of course, an app.config file implies we’re creating an application, not a task. And I’ll leave you with that thought until the next post…