web-dev-qa-db-fra.com

Impossible de charger le fichier ou l'assembly 'msshrtmi' ou l'une de ses dépendances (Azure Table Storage Access)

J'ai un HTTPModule que j'utilise pour rediriger le trafic entre un site Web dans mon centre de données et un site Web fonctionnant sur la plateforme Azure. Ce HTTPModule récupère ses règles de redirection depuis Azure Table Storage.

Les redirections fonctionnent correctement sur ma machine de développement locale ainsi que lors de l'exécution sur Azure. Cependant, lorsque je déploie le module sur mes serveurs de centre de données (IIS 7, WS 2008 R2 Standard 64 bits, .NET 4.0, ASP.NET 4.0) je reçois l'erreur suivante

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" existe réellement dans mon répertoire bin de déploiement.

Si je supprime cette DLL, le site du centre de données fonctionne correctement, mais le module HTTP ne parvient pas à charger ses données de configuration à partir du stockage de table et génère à la place l'erreur suivante

---> 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()

En outre, j'ai inclus manuellement "Microsoft.WindowsAzure.ServiceRuntime.dll" dans le cadre du déploiement pour m'assurer qu'il est disponible sur les serveurs du centre de données.

c#.netazurehttpmoduleazure-storage
49
William Edmondson

Il semble que les projets Azure soient très sensibles à ce fichier particulier. De: http://social.msdn.Microsoft.com/Forums/en-US/windowsazuretroubleshooting/thread/0fac1f05-eb55-432f-80ac-6f15cde5b14b/

Lorsque vous effectuez une reconstruction pour le projet de rôle Web, puis-je vous demander de vérifier si un fichier msshrtmi.dll dans le dossier bin ou non? Si oui, vérifiez s'il s'agit de 64 bits ou 32 bits à l'aide de Dependency Walker. S'il s'agit de 32 bits, essayez l'une des options suivantes pour empêcher la sortie de ce fichier dll dans le dossier bin.

  1. Ciblez le projet de rôle Web sur x64 et recréez le projet de service Azure. Cette option a été confirmée par http://social.msdn.Microsoft.com/Forums/en/windowsazure/thread/286cecf6-1423-4ef3-93f9-0eb8a67d8192. (modifier: maintenant un lien mort en février '12.)

  2. Ouvrez le fichier de projet de site Web à l'aide du Bloc-notes et supprimez l'élément PlatformTarget de tous les groupes de propriétés de configuration. Cette option est citée de http://tomkrueger.wordpress.com/2010/07/27/Azure-deployment-issue-after-upgrading-to-visual-studio-2010-and-net-4-0 / .

  3. Écrivez la commande d'événement post-génération pour supprimer msshrtmi.dll lorsqu'une action de génération est correctement effectuée. Pour ce faire, cliquez avec le bouton droit sur le projet de rôle Web et sélectionnez Propriétés. Sélectionnez l'onglet Build Events, dans la zone de texte "Post-build event command line", entrez la commande suivante:

cd $(TargetDir)del msshrtmi.dll

Tout cela suggère que vous voudrez vérifier que vous avez créé la configuration correcte pour le déploiement sur votre environnement cible. Assurez-vous que vous avez ciblé x64 pour le déploiement sur vos serveurs de centre de données.

30
Jeremy McGee

Cela a résolu le problème pour moi. Exécutez cette commande dans l'invite de commandes développeur pour 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"

Cela enregistrera les fichiers d'exécution dans le Global Assembly Cache afin que toutes les applications .NET y aient accès.

19
Gael Fraiteur

Je viens de tomber sur ce message parce que j'ai eu le même problème - et malheureusement aucune des étapes ci-dessus n'a fonctionné pour moi .

Après un peu de grattage de tête et de déconner - j'ai trouvé la solution, qui était remarquablement/embarrassante simple.

J'ai blogué à ce sujet ici .

  • Cliquez avec le bouton droit sur votre projet Azure (celui avec le globe bleu).
  • Cliquez sur l'onglet "Application".
  • Notez qu'un bouton vous indique qu'un nouveau SDK est installé? CLIQUEZ ICI!

Il s'avère donc que quelques modifications mineures sont apportées à quelques fichiers qui font toute la différence:

  • . Fichier csdef - 'schemaVersion' est mis à jour.
  • . ccproj - 'ProductVersion' et 'CloudExtensionsDir' sont mis à jour.
  • . csproj - Vos références Azure SDK seront mises à jour (ServiceRuntime, Diagnostics etc.)

Je pense que le tueur était le 'CloudExtensionsDir' pour moi, cela a changé DE:

<CloudExtensionsDir Condition=" '$(CloudExtensionsDir)' == '' ">
  $(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\Windows Azure Tools\1.7\
</CloudExtensionsDir>

À:

<CloudExtensionsDir Condition=" '$(CloudExtensionsDir)' == '' ">
  $(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\Windows Azure Tools\1.8\
</CloudExtensionsDir>

Déployé sur Azure, a fonctionné immédiatement.

J'espère que cela t'aides!

PS: Je devrais ajouter que je n'avais pas besoin de désinstaller les anciens SDK ou quoi que ce soit ou de jouer avec les 'Platform Targets'. Le simple fait de changer cela a bien fonctionné.

18
Rob Cooper

Je suis tombé sur cela après avoir traité ce problème pendant longtemps. Ça m'a aidé.

http://mictorino.wordpress.com/2011/09/20/vs2010-build-configurations-and-msshrtmi-dll-x86

3
BZink

J'ai récemment vécu cela et j'ai déterminé que, dans mon cas au moins, cette erreur était due à une référence à Microsoft.WindowsAzure.ServiceRuntime qui était plus ancienne que la version actuelle du SDK.

Dans mon cas, je venais de passer au SDK 2.2, mais mes références ServiceRuntime étaient toujours 2.1, la mise à jour de ces références vers 2.2 a résolu le problème sans que je doive faire référence à msshrtmi.dll.

2
hermiod

Je peux être fou, mais cela m'est arrivé parce que le SDK Windows Azure N'A PAS ÉTÉ MÊME INSTALLÉ. Stupide, je sais, mais utile à surveiller dans certaines situations.

2
Ohad Schneider

Ce problème m'a mis sur écoute au cours des deux derniers jours, et toutes les solutions mentionnées ici et sur d'autres sites Web n'ont pas fonctionné.

Maintenant, je l'ai enfin fait fonctionner. Le problème était une mauvaise combinaison de SDK et de versions d'outils installés sur ma machine. Il y a quelques jours, j'ai téléchargé ce qui suit:

  • Windows Azure Tools 1.7
  • Aperçu du SDK Windows Azure pour Visual Studio 2012 (juin 2012)

Je savais que le SDK Azure était un aperçu, mais certaines notes de publication m'ont fait croire qu'il comprenait la version actuelle du SDK (stable) pour Visual Studio 2010.

Après avoir désinstallé l'aperçu et installé Windows Azure SDK for .NET (VS 2010 SP1) - June 2012, tout a parfaitement fonctionné.

2
cheeesus

J'ai résolu le problème que nous rencontrions en ajoutant simplement une référence à

C:\Program Files\Microsoft SDKs\Windows Azure.NET SDK\2012-06\bin\runtimes\base\x86\msshrtmi.dll

Cela ne fonctionnera probablement pas pour tous les scénarios mais vaut la peine d'être essayé.

2
Lee Englestone

Ajoutez simplement le dossier "_ bin_deployableAssemblies" dans votre projet. Placez le fichier "C:\Program Files\Microsoft SDKs\Windows Azure.NET SDK\2012-06\bin\runtimes\base\x64\msshrtmi.dll" dans ce dossier. Changez l'action de construction en "Aucun" et déployez simplement ...

C'est du travail pour moi ...

2
Tuizi

J'ai changé la propriété "Copy Local" en "False". Et ça a marché pour moi.

Étapes:

  1. Allez à la référence.
  2. Ouvrez les propriétés de la DLL à partir de la référence.
  3. Remplacez la propriété "Copy Local" par False.
0
Dark Matter

J'ai rencontré une erreur similaire lors de l'utilisation d'une solution déployable à la fois sur Windows Azure et sur du matériel physique. L'erreur apparaîtrait lors de la tentative d'exécution de la solution sur du matériel physique. Le problème provenait du fait que les bibliothèques Azure faisaient partie de la solution, même si elles n'étaient pas requises pour la génération sur site.

La solution simple consiste à installer le SDK Windows Azure sur le matériel physique. Cela installera les bibliothèques manquantes dans le GAC

0
Iain Hunter

J'ai résolu le problème en ajoutant msshrtmi à GAC.

0
Matej

Cette solution fonctionne pour moi:

  • Ouvrez le projet avec un bloc-notes
  • Supprimer toutes les balises "PlatformTarget" sous tous les "PropertyGroup"
0
camaya

J'ai pu contourner ce problème en m'assurant que je faisais référence à la version X64 de msshrtmi.dll dans le GAC [1] (pour correspondre à la cible de plate-forme x64 définie sur le projet).

[1] c:\Windows\Assembly\GAC_64\msshrtmi\1.7.0.0__31bf3856ad364e35>

0
Vishwas Lele

Ma solution à ce problème a été d'expédier msshrtmi.dll (x86 et x64) avec mon application, puis de les charger dynamiquement en cas de besoin.

Voir http://jake.ginnivan.net/Azure-and-msshrtmi

0
Jake Ginnivan

J'avais le même problème.

De votre dossier/sous-dossiers de solution, supprimez tous les fichiers "msshrtmi.dll" puis reconstruisez.

0
vidalsasoon