Putting Managed Extensibility Framework (MEF) in your Windows Azure Application while trying to test your code using Visual Studio 2010 does not work OOTB. It is quite easy to modify – in this case MEF – to enable this scenario. The same issue might result from using other libraries as well.
Now that Visual Studio 2010 is out you really do not want to remain on the old version. Sometimes there can be issues working with applications that need to support previous versions of .NET Framework – previous to .NET 4.0 that is. Here is one such issue and how you work around it.
UPDATE: There was one more problem that I did not cover in this post. Once you’ve read this. Continue reading here MEF + Azure + Visual Studio 2010 = Tricky but doable (Part 2) in order to get the final piece of the puzzle.
Note: This issue will go away within a couple of months when .NET Framework 4.0 is deployed to Windows Azure. But right now this may be an issue. Guess the blogging window for this topic is right now. ;~)
Note to self: Stop doing epic refactoring and development tasks on your small(ish) projects. This will halt your blogging.
Prologue
Testing in Visual Studio 2010 requires you to run the new version of the Microsoft.VisualStudio.QualityTools.UnitTestFramework. This artifact is built using .NET Framework 4.0.
If you go File –> New –> Windows Azure Cloud Service project and select an ASP.NET MVC 2.0 Web Role and choose to create also a Test Project for this solution you will get one Web App on .NET Framework 3.5 and one Test Project on .NET Framework 4.0. If you want to develop your Windows Azure Application using Visual Studio 2010 your Azure app requires .NET Framework 3.5 because Windows Azure is on .NET Framework 3.5.
Can you see a versioning conflict a’ brewin’? ;~)
The Problem
Some parts of Windows Azure Applications is a classic extensibility scenario. My colleague Peter and I used a standard .NET Framework library in preview called Managed Extensibility Framework (MEF) to handle extensibility. This worked fine for the old version of Visual Studio but results in a conflict in Visual Studio 2010. MEF includes a couple of small utility classes from .NET Framework 4.0 as part of the preview. These are embedded in the System.ComponentModel.Composition assembly that is MEF. If you try to reference this assembly from your Visual Studio 2010 test project you will first fail. Visual Studio is smart enough to instead not do as you ask but rather go and reference the assembly that is part of your .NET Framework 4.0 installation:
But if you use the preview version of MEF that is compiled against .NET Framework 3.5 in your Windows Azure Application you have to have this particular version referenced in your tests. If you run your tests using the 4.0 version of MEF in your Test Project and the 3.5 version in your Azure Role you will get this error:
It appears you cannot load the 3.5 version of MEF when you have already loaded a newer (4.0) version when you run your test.
The Solution
How do I add the version I want (3.5) then? Let’s resort to good old hand editing of the project file:
I opened up my Azure Role project file in notepad and copied my reference to MEF:
<Reference Include="System.ComponentModel.Composition">
<HintPath>..\lib\System.ComponentModel.Composition.dll</HintPath>
</Reference>
Then I opened up the Visual Studio 2010 Test Project file in notepad and replaced the following with the text above:
<Reference Include="System.ComponentModel.Composition" />
Hey presto! It works.
Summary
UPDATE: There was one more problem that I did not cover in this post. Once you’ve read this. Continue reading here MEF + Azure + Visual Studio 2010 = Tricky but doable (Part 2) in order to get the final piece of the puzzle.
If there is a will there is a way. Due to the collision between the MEF Preview that works in .NET Framework 3.5 and the Visual Studio 2010 Test Project type which defaults to the .NET Framework 4.0 version it was non-trivial to use the MEF library in the Cloud.
Using MEF in Windows Azure is something I automatically turned to when I saw that my scenario had an open ended extensibility point. Since you know what it is you deploy to Windows Azure and if you are not using a bunch of third party libraries that might utilize extensibility through MEF it is unlikely that this problem will apply to you.
That said if you are stringent about using the right tool for the right job and strive to make your code designs and software architecture adhere to a good yet for your domain appropriate number of design patterns and techniques then MEF will very likely find it’s way into Your Application in the Cloud.
Cheers,
M.
posted @ Wednesday, April 28, 2010 8:51 PM