I have an HTTPModule that I use to redirect traffic between a website in my data center and a website running on the Azure platform. This HTTPModule retrieves its redirect rules from Azure Table Storage.
Redirects work fine on my local dev machine as well as when running on Azure. However, when I deploy the module to my data center servers ( IIS 7, WS 2008 R2 Standard 64bit, .NET 4.0, ASP.NET 4.0 ) I receive the following error
Parser Error Message: Could not load file or assembly 'msshrtmi' or one of its dependencies. An attempt was made to load a program with an incorrect format.
Line 124: <add assembly="System.Web.DynamicData, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
Line 125: <add assembly="System.Web.ApplicationServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
Line 126: <add assembly="*" />
Line 127: </assemblies>
Line 128: <buildProviders>
Source File: C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\web.config Line: 126
"msshrtmi.dll" actually exists in my deployment bin directory.
If I remove this dll the data center site works fine but but the HTTPModule fails to load its configuration data from Table Storage and instead throws the following error
---> System.TypeInitializationException: The type initializer for 'Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment' threw an exception. ---> System.IO.FileNotFoundException: Could not load file or assembly 'msshrtmi, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
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()
Also, I have manually included "Microsoft.WindowsAzure.ServiceRuntime.dll" as part of the deployment to ensure it is available on the data center servers.
It seems that Azure projects are very sensitive to that particular file. From: http://social.msdn.microsoft.com/Forums/en-US/windowsazuretroubleshooting/thread/0fac1f05-eb55-432f-80ac-6f15cde5b14b/
When you do a rebuild for the web role project, may I ask you to check if a msshrtmi.dll file in the bin folder or not? If yes, then please check if it is 64bit or 32bit using Dependency Walker. If it is 32bit, please try either of the following options to prevent outputing this dll file to bin folder.
Target the web role project to x64 and recreate the azure service project. This option was confirmed by
http://social.msdn.microsoft.com/Forums/en/windowsazure/thread/286cecf6-1423-4ef3-93f9-0eb8a67d8192. (edit: now a dead link as at February '12.)Open the web site project file using Notepad and remove the PlatformTarget element from all configuration property groups. This option is quoted from http://tomkrueger.wordpress.com/2010/07/27/azure-deployment-issue-after-upgrading-to-visual-studio-2010-and-net-4-0/.
Write Post-build event command to delete msshrtmi.dll when a build action is successfully performed. To do this, please right click the web role project and select Properties. Select the Build Events tab, in the "Post-build event command line" textbox, input the following command:
cd $(TargetDir)
del msshrtmi.dll
This all suggests that you'll want to check that you've built the correct configuration for deployment on your target environment. Make sure you've targetted x64 for deployment to your data centre servers.
This solved the problem for me. Run this command within the Developer Command Prompt for VS2013.
gacutil /i "C:\Program Files\Microsoft SDKs\Windows Azure\.NET SDK\v2.0\bin\runtimes\base\x64\msshrtmi.dll"
gacutil /i "C:\Program Files\Microsoft SDKs\Windows Azure\.NET SDK\v2.0\bin\runtimes\base\x86\msshrtmi.dll"
This will register the runtime files in the Global Assembly Cache so all .NET applications will have access to it.
I've just come across this post because I had the same issue - and unfortunately none of the above steps worked for me.
After a bit of head-scratching and messing around - I found the solution, which was remarkably/embarrassingly simple.
I blogged about it here.
So, it turns out that some minor changes get made to a few files that make all the difference:
schemaVersion
' is updated.ProductVersion
' and 'CloudExtensionsDir
' are updated.I think the killer was the 'CloudExtensionsDir
' for me, this changed FROM:
<CloudExtensionsDir Condition=" '$(CloudExtensionsDir)' == '' ">
$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\Windows Azure Tools\1.7\
</CloudExtensionsDir>
TO:
<CloudExtensionsDir Condition=" '$(CloudExtensionsDir)' == '' ">
$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\Windows Azure Tools\1.8\
</CloudExtensionsDir>
Deployed to Azure, worked straight away.
Hope this helps!
PS: I should add, that I didn't need to uninstall any of the old SDK's or anything or mess around with 'Platform Targets'. Just changing this worked fine.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With