In my previous Developing MSBee post, I began discussing how the ResolveComReference task is being implemented. As I mentioned, we want to produce .NET 1.1 COM interop when necessary. Consequently, our code must run with .NET 1.1. To do that, I proposed using an app.config file and then you wondered why would I have an app.config file if I’m making a task? Well, it turns out that I’m not just making a task.

 

The MSBee DLL will contain a ResolveComReference (RCR) ToolTask that has the same properties as the MSBuild ResolveComReference task. However, the tool task will run an executable that does the actual work of resolving COM references. This executable contains the MSBuild team’s ResovleComReference code, along with pieces of their Framework and Utilities DLLs. This allows us to leverage their code and just replace the .NET 2.0 specific pieces with .NET 1.1 equivalents. Naturally, we’re dogfooding MSBee to build the application.

 

To transfer our RCR task’s properties to the executable, we place some values on the command line as switches and others are written into a temporary response file. The executable parses its command line and processes the response file to retrieve the task’s input. When the executable finishes, it writes the resolved COM reference data, which is stored as TaskItems, into a temp file. The RCR task will process the temp file when the executable returns and add the TaskItems to the appropriate output arrays. Unfortunately, TaskItems are not Serializable so the TaskItem metadata is manually converted into a string before it’s written to a file. When a file containing TaskItem metadata is processed, it must rebuild each TaskItem by parsing its string.

 

So, that’s a condensed explanation of how the ResolveComReference task will work in MSBee. One unfortunate result of this approach is that the executable itself will not be shared source since it contains intellectual property. However, the RCR tool task will be shared source along with the other MSBee tasks.