Why am I getting SEHException when calling RoleEnvironment.GetConfigurationSettingValue(“MYKEY”)?

Question

I\'m trying to call RoleEnvironment.GetConfigurationSetting(\"SOMEKEY\") like so:

public partial class AzureBasePage : System.Web.UI.Page
{
             


        

Answer 1

If you get the same error after making sure you are running the dev fabric, try reducing the instance count to one. That fixed it for me.

Still, seems weird that I can't debug with 2 instances.

Answer 2

To follow up on that, just in case someone runs into the same problem again, it might also be the case that for whatever reason one of your deployments got stuck in the compute emulator.

What happened to me was that I had a webrole containing multiple websites, each bound to a different hostname. Say: localhost and test.localhost. Normally, you would access these at localhost:81 and test.localhost:81. For some strange reason though, one deployment got into a weird state where it would be listed in the compute emulator, with no Visual Studio debugging it, it would say "Role Instance destroyed" or something along those lines.. This deployment still had the websites deployed in IIS. I then, without knowing about this buggy deployment, accessed the default urls, ie. test.localhost:81 which would load up the old deployment files. The (old) site worked until I opened a page that actually used the RoleEnvironment.GetConfigurationSettingValue method, and only then I got that exception. It was really frustrating as this boggus deployment obvioulsy didn't hit any breakpoints nor breaked on exceptions, yet it looked exactly as the site I've been working on..

When I realised this, I opened the hostnames under the new port and there the pages worked as expected. Once I removed this buggy deployment from the compute emulator the IIS websites also got deleted and thankfully the ports are now available for use as expected..

Answer 3

You will get the SEHException if you attempt to access RoleEnvironment if you're not running in the dev fabric or Azure fabric. I believe you're inadvertently running your website under the asp.net development server, meaning you're not in the dev fabric (I've confirmed that this will throw an SEHException). In other words, you've either set your website project as the startup project, or you've right-clicked it and told it to run.

You must set the cloud project itself as the startup project, which will then show your website running on port 81 by default. The cloud project is the project that has, as its members, all of your role definitions. You can look at your browser's URL bar and easily tell if you're running in the asp.net dev server, because you'll be on some random port number instead of port 81.

You should make sure you're running in the dev fabric or Azure fabric by checking RoleEnvironment.IsAvailable. If that's true, you're safe to call anything in RoleEnvironment. If it's false, you're not running within the fabric.

Answer 4

Although many point out that you should run with dev/Azure fabric instead of the asp.net development server, I think it's worth mentioning that you need to choose the correct execution model when you publish your application to Azure if you want to use the RoleEnvironment.

There're 3 models as of now:

• VM
• Web Site
• Cloud Service

Please refer to here: http://azure.microsoft.com/en-us/documentation/articles/fundamentals-application-models for more details.

And especially the following paragraph:

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.

You can check the RoleEnvironment.IsAvailable. If it is false, your application is not running with Azure runtime, which means the RoleEnvironment is not applicable.

Answer 5

Removing the <Sites> tag in the ServiceDefinition.csdef file could be a workaround for you as was for us but then your site will not be deployed to Full IIS on the Cloud. We are using 1.7 of the SDK.

So in summary: RoleEnvironment.IsAvailable = False with this included in the ServiceDefinition.csdef with an instance count of 1 I might add.

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

Remove the <Sites> node and deploy and you might find that now RoleEnvironment.IsAvailable = True.

There are very little logs about what is actually happening - the website is running fine, there are no warnings except the usual you only have 1 instance why not deploy 2 and the site is up and running fine.

This is a recent issue and I believe there must be some changes made in that msshrtmi.dll. It could log a little more of what might actually be the problem if the RoleEnvironment is not available.