c# - proyecto - No se pudo cargar el archivo o ensamblado ''msshrtmi'' o una de sus dependencias(Azure Table Storage Access)

no se puede cargar el archivo o ensamblado mysql connector install (15)

Acabo de encontrar esta publicación porque tenía el mismo problema, y desafortunadamente ninguno de los pasos anteriores funcionó para mí .

Después de un poco de rascarse la cabeza y meter la pata, encontré la solución, que era notablemente embarazosamente simple.

Blogé sobre esto here .

Haga clic derecho en su proyecto Azure (el que tiene el globo azul).
Haga clic en la pestaña "Aplicación".
Tenga en cuenta que hay un botón que le indica que tiene instalado un SDK más nuevo. ¡PINCHALO!

Por lo tanto, resulta que se realizan algunos cambios menores en algunos archivos que marcan la diferencia:

Archivo .csdef - '' schemaVersion '' se actualiza.
.ccproj - '' ProductVersion '' y '' CloudExtensionsDir '' se actualizan.
.csproj : sus referencias de Azure SDK se actualizarán (ServiceRuntime, Diagnostics, etc.)

Creo que el asesino fue el '' CloudExtensionsDir '' para mí, esto cambió FROM:

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

Desplegado a Azure, funcionó de inmediato.

¡Espero que esto ayude!

PD: Debo agregar, que no necesité desinstalar ninguno de los viejos SDK ni nada, ni meterme con ''Platform Targets''. Solo cambiar esto funcionó bien.

Tengo un HTTPModule que utilizo para redirigir el tráfico entre un sitio web en mi centro de datos y un sitio web que se ejecuta en la plataforma Azure. Este HTTPModule recupera sus reglas de redirección de Azure Table Storage.

Los redireccionamientos funcionan bien en mi máquina de desarrollo local, así como también cuando se ejecutan en Azure. Sin embargo, cuando despliego el módulo a los servidores de mi centro de datos (IIS 7, WS 2008 R2 Standard 64bit, .NET 4.0, ASP.NET 4.0) recibo el siguiente 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" realmente existe en mi directorio bin de despliegue.

Si elimino este archivo DLL, el sitio del centro de datos funciona bien, pero el HTTPModule no puede cargar sus datos de configuración desde el Almacenamiento de tabla y arroja el siguiente 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()

Además, he incluido manualmente "Microsoft.WindowsAzure.ServiceRuntime.dll" como parte de la implementación para garantizar que esté disponible en los servidores del centro de datos.

Esta solución funciona para mí:

Abra el proyecto con un bloc de notas
Eliminar todas las etiquetas "PlatformTarget" debajo de todo "PropertyGroup"

Estaba teniendo el mismo problema.

Desde la carpeta / subcarpetas de la solución, elimine todos los archivos "msshrtmi.dll" y vuelva a generarlos.

Este problema me ha molestado durante los últimos dos días, y todas las soluciones mencionadas aquí y en otros sitios web no funcionaron.

Ahora finalmente lo tengo trabajando. El problema era una mala combinación de SDK y versiones de herramientas instaladas en mi máquina. Hace algunos días descargué lo siguiente:

Windows Azure Tools 1.7
Vista previa de Windows Azure SDK para Visual Studio 2012 (junio de 2012)

Sabía que Azure SDK era una vista previa, pero algunas notas de la versión me hicieron creer que incluía la versión actual del SDK (estable) para Visual Studio 2010.

Después de desinstalar la vista previa e instalar Windows Azure SDK for .NET (VS 2010 SP1) - June 2012 , todo funcionó a la perfección.

Esto resolvió mi problema. Ejecute este comando dentro del indicador de comandos del desarrollador para 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"

Esto registrará los archivos de tiempo de ejecución en Global Assembly Cache para que todas las aplicaciones .NET tengan acceso a él.

He resuelto el problema al agregar msshrtmi a GAC.

Lo experimenté recientemente y determiné que, en mi caso al menos, este error fue causado por tener una referencia a Microsoft.WindowsAzure.ServiceRuntime que era anterior a la versión actual del SDK.

En mi caso, acababa de actualizar a SDK 2.2 pero mis referencias de ServiceRuntime seguían siendo 2.1, actualizando estas referencias a 2.2 resolví el problema sin tener que hacer referencia a msshrtmi.dll.

Me encontré con esto después de lidiar con este problema durante mucho tiempo. Me ayudó.

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

Mi solución a este problema fue enviar msshrtmi.dll (tanto x86 como x64) con mi aplicación, luego cargarlos dinámicamente cuando sea necesario.

Ver http://jake.ginnivan.net/azure-and-msshrtmi

Parece que los proyectos de Azure son muy sensibles a ese archivo en particular. De: http://social.msdn.microsoft.com/Forums/en-US/windowsazuretroubleshooting/thread/0fac1f05-eb55-432f-80ac-6f15cde5b14b/

Cuando realice una reconstrucción para el proyecto de rol web, ¿puedo pedirle que compruebe si un archivo msshrtmi.dll está en la carpeta bin o no? En caso afirmativo, compruebe si se trata de 64 bits o 32 bits utilizando Dependency Walker. Si es de 32 bits, intente cualquiera de las siguientes opciones para evitar la salida de este archivo dll a la carpeta bin.
Oriente el proyecto de rol web a x64 y vuelva a crear el proyecto de servicio azul. Esta opción fue confirmada por ~~http://social.msdn.microsoft.com/Forums/en/windowsazure/thread/286cecf6-1423-4ef3-93f9-0eb8a67d8192~~ . (Editar: ahora un enlace inactivo a febrero de 12).
Abra el archivo de proyecto del sitio web con el Bloc de notas y elimine el elemento PlatformTarget de todos los grupos de propiedades de configuración. Esta opción se cita de http://tomkrueger.wordpress.com/2010/07/27/azure-deployment-issue-after-upgrading-to-visual-studio-2010-and-net-4-0/ .
Escriba el comando de evento Post-build para eliminar msshrtmi.dll cuando se realiza con éxito una acción de compilación. Para hacer esto, haga clic con el botón derecho en el proyecto de rol web y seleccione Propiedades. Seleccione la pestaña Build Events, en el cuadro de texto "Post-build event command line", ingrese el siguiente comando:
cd $(TargetDir) del msshrtmi.dll

Todo esto sugiere que deseará comprobar que ha creado la configuración correcta para la implementación en su entorno de destino. Asegúrese de tener como objetivo x64 para la implementación en los servidores de su centro de datos.

Pude solucionar este problema asegurándome de que estaba haciendo referencia a la versión X64 de msshrtmi.dll en el GAC [1] (para que coincida con el objetivo de la plataforma de x64 establecido en el proyecto).

[1] c: / Windows / assembly / GAC_64 / msshrtmi / 1.7.0.0__31bf3856ad364e35>

Puede que esté loco, pero esto me pasó porque el SDK de Windows Azure NO ESTABA INSTALADO . Estúpido, lo sé, pero útil para vigilar en ciertas situaciones.

Simplemente agregue la carpeta " _bin_deployableAssemblies " en su proyecto. Coloque el archivo " C: / Archivos de programa / Microsoft SDK / Windows Azure.NET SDK / 2012-06 / bin / runtimes / base / x64 / msshrtmi.dll " en esta carpeta. Cambie la acción de compilación a " Ninguno " y solo implemente ...

Es trabajo para mí ...

Solucioné el problema que teníamos simplemente agregando una referencia a

C: / Archivos de programa / Microsoft SDK / Windows Azure.NET SDK / 2012-06 / bin / runtimes / base / x86 / msshrtmi.dll

Probablemente no funcionará para todos los escenarios, pero vale la pena intentarlo.

Sufrí de un error similar al trabajar con una solución que se podía implementar tanto en Windows Azure como en hardware físico. El error se mostraría al intentar ejecutar la solución en el hardware físico. El problema se originó en el hecho de que las bibliotecas de Azure formaban parte de la solución, a pesar de que no eran necesarias para la construcción en las instalaciones.

La solución más simple es instalar Windows Azure SDK en el hardware físico. Esto instalará las bibliotecas faltantes en el GAC