FileLoadException in Unit Test on RoleEnvironment.IsAvailable with Visual Studio 2012 RC with Azure SDK 1.7
Problem and Solution
While upgrading to VS2012 Pro RC, my unit tests began to fail across the board when accessing various Azure APIs like RoleEnvironment.IsAvailable. I would get the exception below consistently:
System.TypeInitializationException: The type initializer for 'Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment' threw an exception. ---> System.IO.FileLoadException: Mixed mode assembly is built against version 'v2.0.50727' of the runtime and cannot be loaded in the 4.0 runtime without additional configuration information.
Result StackTrace:
at Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.InitializeEnvironment()
at Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment..cctor()
--- End of inner exception stack trace ---
at Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.get_IsAvailable()
To reproduce this, I would do the following:
- Prerequisites: VS2012RC, .NET SDK for 1.7 Azure release (and it's dependencies from https://www.windowsazure.com/en-us/develop/net/)
- Open VS2012RC
- Create a new Test => Unit Test project
- Add a reference to Microsoft.WindowsAzure.ServiceRuntime from: c:\Program Files\Microsoft SDKs\Windows Azure\.NET SDK\2012-06\ref\Microsoft.WindowsAzure.ServiceRuntime.dll
- Add the following code to the default test file:
using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Microsoft.WindowsAzure.ServiceRuntime;
namespace UnitTestProject1
{
[TestClass]
public class UnitTest1
{
[TestMethod]
public void TestMethod1()
{
if (!RoleEnvironment.IsAvailable)
{
Console.WriteLine("The Azure RoleEnvironment is not available. This is the expected output.");
}
else
{
Console.WriteLine("The Azure RoleEnvironment is available. This should never happen.");
}
}
}
}
Run the test using Test Explorer and the test should fail with approximately the output that I initially indicated. To work around this problem (which I feel I should not have had to), I did the following:
- Started my test in the debugger
- Identified the PID of the process using System.Diagnostics.GetCurrentProcess().Id
- Mapped that in task manager to "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.executionengine.x86.exe"
- Opened the vstest.executionengine.x86.exe.config file in a text editor and added the following XML below the <configuration> opening tag:
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
</startup>
- Closed and reopened Visual Studio
- Reran my test
- Success - The test passed and had the expected output on the console.
Before attempting this relatively hackish solution, I did also try putting the startup configuration element in an app.config for the test project as well as machine.config, but to no avail. I did repro the problem in a simple console application but was able to use this workaround by placing the tag in that console app's app.config.
Questions and Concerns
I don't think that I should have had to take the above steps to work around this problem. Can anyone explain to me why the default configuration of my system after installing Dev11 RC behaved this way? Note that I also have VS2010 Pro installed with the 1.6 SDK and the 1.7 SDK. Are these pre-existing installations part of the problem?
While researching this problem, I came across many different articles and posts talking about similar problems, but none with quite the solution I needed. For reference, I also spent time trying to absorb this post for detailed backround on the configuration attribute in play here: https://www.marklio.com/marklio/PermaLink,guid,ecc34c3c-be44-4422-86b7-900900e451f9.aspx
If you know the root cause of this and why I had to work around it, I'd love to know. I'm going to guess I won't be the only one seeing this. I hope this problem does not resurface with the GA release of VS2012 and/or that my system configuration is somehow unique. Note that I'm developing on Windows Server 2008 R2 (not that that should matter).
~Cheers
Sean
Comments
Anonymous
July 02, 2012
Thanks! I had the same issue and your solution worked.Anonymous
October 25, 2012
Your configuration was certainly not unique and it has surfaced in the GA release. Wish I knew what was going on. I'll try to find another solution and report back here if I find anything. Thanks for the post!Anonymous
January 18, 2013
Thanks for this. Upgrading to Azure 1.8 has been harder than pulling my own healthy teeth outAnonymous
September 19, 2013
Great! This solved the same issue that I had. Thank you!Anonymous
May 11, 2014
The comment has been removed