¿Por qué recibo SEHException cuando llamo a RoleEnvironment.GetConfigurationSettingValue ("MYKEY")?

Question

estoy tratando de llamar RoleEnvironment.GetConfigurationSetting("SOMEKEY") así:

public partial class AzureBasePage : System.Web.UI.Page 
{ 
    protected ChargifyConnect Chargify 
    { 
     get { 
      if (this._chargify == null) { 
       this._chargify = new ChargifyConnect(); 
       this._chargify.apiKey = RoleEnvironment.GetConfigurationSettingValue("CHARGIFY_API_KEY"); 
      } 
      return this._chargify; 
     } 
    } 
    private ChargifyConnect _chargify = null; 
} 

Mi llave ServiceConfiguration.cscfg se ve así:

<Setting name="CHARGIFY_API_KEY" value="AbCdEfGhIjKlMnOp" /> 

Y me da este error:

Exception Details: System.Runtime.InteropServices.SEHException: External component has thrown an exception.

[SEHException (0x80004005): External component has thrown an exception.] RoleEnvironmentGetConfigurationSettingValueW(UInt16* , UInt16* , UInt32 , UInt32*) +0 Microsoft.WindowsAzure.ServiceRuntime.Internal.InteropRoleManager.GetConfigurationSetting(String name, String& ret) +92 Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.GetConfigurationSettingValue(String configurationSettingName) +67 ChargifyNET.ChargifyAzurePage.get_Chargify() in C:\NetProjects\ChargifyDotNET\Source\Chargify.NET\ChargifyAzurePage.cs:26 Chargify.Azure._Default.Page_Load(Object sender, EventArgs e) in C:\NetProjects\ChargifyDotNET\Source\Chargify.Azure\Default.aspx.vb:8 System.Web.UI.Control.OnLoad(EventArgs e) +99 System.Web.UI.Control.LoadRecursive() +50 System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +627

Answer 1

Se hará obtenga la SEHException si intenta acceder a RoleEnvironment si no está ejecutándose en el tejido dev o en Azure Fabric. Creo que inadvertidamente está ejecutando su sitio web en el servidor de desarrollo asp.net, lo que significa que no está en el tejido de desarrollo (he confirmado que esto arrojará una SEHException). En otras palabras, ha configurado el proyecto de su sitio web como el proyecto de inicio o lo ha hecho clic derecho y le indicó que se ejecute.

Debe establecer el proyecto de la nube en sí como el proyecto de inicio, que luego mostrará su sitio web ejecutándose en el puerto 81 de forma predeterminada. El proyecto de la nube es el proyecto que tiene, como sus miembros, todas las definiciones de su función. Puede ver la barra de direcciones URL de su navegador y saber fácilmente si se está ejecutando en el servidor de desarrollo asp.net, porque estará en un número de puerto aleatorio en lugar del puerto 81.

Debe asegurarse de estar ejecutándose en el tejido dev o en el tejido Azure marcando RoleEnvironment.IsAvailable. Si eso es cierto, puedes llamar a cualquier cosa en RoleEnvironment. Si es falso, no se está ejecutando dentro del tejido.

Answer 2

Para continuar con esto, en caso de que alguien vuelva a encontrarse con el mismo problema, también podría darse el caso de que por alguna razón una de sus implementaciones se quedara atascada en el emulador de cómputo.

Lo que me sucedió fue que tenía un webrole que contenía varios sitios web, cada uno vinculado a un nombre de host diferente. Diga: localhost y test.localhost. Normalmente, tendría acceso a estos en localhost: 81 y test.localhost: 81. Sin embargo, por alguna extraña razón, una implementación llegó a un estado extraño donde se enumeraría en el emulador de cómputo, sin que Visual Studio lo depurara, diría "Instancia de rol destruida" o algo similar. Esta implementación aún tenía el sitios web desplegados en IIS. Entonces, sin saber sobre esta implementación defectuosa, accedí a las direcciones URL predeterminadas, es decir. test.localhost: 81 que cargaría los archivos de implementación anteriores. El (viejo) sitio funcionó hasta que abrí una página que realmente usaba el método RoleEnvironment.GetConfigurationSettingValue, y solo entonces obtuve esa excepción. Fue realmente frustrante ya que esta implementación de Boggi no llegó a ningún punto de ruptura ni a excepciones, pero se veía exactamente como el sitio en el que he estado trabajando ...

Cuando me di cuenta de esto, abrí los nombres de host bajo nuevo puerto y allí las páginas funcionaron como se esperaba. Una vez que eliminé esta implementación errónea del emulador de cómputo, los sitios web de IIS también se eliminaron y afortunadamente los puertos están ahora disponibles para su uso como se esperaba.

Answer 3

Si obtiene el mismo error después de asegurarse de que está ejecutando el tejido dev, intente reduciendo el recuento de instancias a uno. Eso lo solucionó para mí.

Aún así, parece raro que no pueda depurar con 2 instancias.

Answer 4

La eliminación de la etiqueta <Sites> en el archivo ServiceDefinition.csdef podría ser una solución para usted como lo fue para nosotros, pero luego su sitio no se implementará en Full IIS en la nube. Estamos usando 1.7 del SDK.

Así que en resumen: RoleEnvironment.IsAvailable = False con esto incluido en el ServiceDefinition.csdef con un número de instancias de 1 que podría agregar.

<Sites> 
     <Site name="Blah"> 
     <Bindings> 
      <Binding name="Endpoint1" endpointName="Http" /> 
      <Binding name="Endpoint1" endpointName="Https" /> 
     </Bindings> 
     </Site> 
</Sites> 

eliminar el nodo <Sites> y desplegar y puede encontrarse con que ahora RoleEnvironment.IsAvailable = True.

Hay muy pocos registros sobre lo que está sucediendo en realidad: el sitio web funciona bien, no hay advertencias, excepto el habitual, solo tiene 1 instancia por qué no implementar 2 y el sitio funciona correctamente.

Este es un problema reciente y creo que debe haber algunos cambios realizados en ese msshrtmi.dll. Podría registrar un poco más de lo que podría ser realmente el problema si el RoleEnvironment no está disponible.

Answer 5

Aunque muchos señalan que se debe ejecutar con dev/tela azul en lugar del servidor de desarrollo asp.net, creo que vale la pena mencionar que tiene que elegir la correcta modelo de ejecución cuando publica su aplicación a Azure si desea utilizar el RoleEnvironment.

Hay 3 modelos a partir de ahora:

• VM
• Sitio Web
• Cloud Service

Por favor remítase a aquí: http://azure.microsoft.com/en-us/documentation/articles/fundamentals-application-models para más detalles.

Y especialmente el párrafo siguiente:

Cloud Services, which was the initial execution model provided by Azure, is an explicitly PaaS approach. While the line between PaaS and web hosting is blurry, Cloud Services differs in some important ways from Web Sites, including the following:

• Unlike Web Sites, Cloud Services gives you administrative access to your application's VMs. This lets you install arbitrary software that your application needs, something that's not possible with Web Sites.
• Because Cloud Services offers both web roles and worker roles, it's a better choice than Web Sites for multi-tier applications that need separate VMs for their business logic.
• Cloud Services provides separate staging and production environments, making application updates somewhat smoother than Web Sites.
• Unlike Web Sites, you can use networking technologies such as Azure Virtual Network and Azure Connect to hook on-premises computers to Cloud Services applications.
• Cloud Services lets you use Remote Desktop to connect directly to an application's VMs, something that's not possible with Web Sites.

Puede comprobar el RoleEnvironment.IsAvailable. Si es falso, su aplicación no se ejecuta con el tiempo de ejecución de Azure, lo que significa que RoleEnvironment no es aplicable.