Почему я получаю SEHException при вызове функции RoleEnvironment.GetConfigurationSettingValue( "MYKEY" )?

Я пытаюсь вызвать RoleEnvironment.GetConfigurationSetting("SOMEKEY") следующим образом:

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

Мой ключ ServiceConfiguration.cscfg выглядит следующим образом:

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

И я получаю эту ошибку:

Сведения об исключении: System.Runtime.InteropServices.SEHException: внешний компонент выбрал исключение.

[SEHException (0x80004005): внешний компонент выбрал исключение.] 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() в C:\NetProjects\ChargifyDotNET\Source\Chargify.NET\ChargifyAzurePage.cs: 26 Chargify.Azure._Default.Page_Load (отправитель объекта, EventArgs e) в 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

Ответ 1

Вы получите SEHException, если вы попытаетесь получить доступ к RoleEnvironment, если вы не работаете в ткани dev или Azure. Я считаю, что вы случайно запускаете свой сайт под сервером разработки asp.net, то есть вы не находитесь в dev-структуре (я подтвердил, что это вызовет исключение SEHException). Другими словами, вы либо задали свой проект веб-сайта как проект запуска, либо вы щелкнули его правой кнопкой мыши и сказали ему, чтобы он выполнялся.

Вы должны установить сам проект облака как проект запуска, который затем покажет ваш веб-сайт, запущенный на порту 81 по умолчанию. Проект облака - это проект, который имеет в качестве своих членов все ваши определения роли. Вы можете посмотреть строку своего браузера и легко узнать, работаете ли вы в сервере asp.net dev, потому что вы будете на некотором случайном номере порта, а не на порту 81.

Вы должны убедиться, что работаете в ткани dev или Azure, проверив RoleEnvironment.IsAvailable. Если это так, вы можете назвать что-либо в RoleEnvironment. Если он ошибочен, вы не работаете внутри этой ткани.

Ответ 2

Удаление тега <Sites> в файле ServiceDefinition.csdef может быть обходным путем для вас, как это было для нас, но затем ваш сайт не будет развернут в Full IIS в Cloud. Мы используем 1.7 SDK.

Итак, вкратце: RoleEnvironment.IsAvailable = False с этим включенным в ServiceDefinition.csdef с числом экземпляров 1, которое я мог бы добавить.

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

Удалите <Sites> node и разверните его, и теперь вы можете найти RoleEnvironment.IsAvailable = True.

Есть очень мало журналов о том, что на самом деле происходит - сайт работает нормально, нет никаких предупреждений, кроме обычного, у вас есть только один экземпляр, почему бы не развернуть 2, и сайт работает нормально.

Это недавняя проблема, и я считаю, что в этом msshrtmi.dll должны быть внесены некоторые изменения. Он мог бы записать немного больше, что может быть проблемой, если RoleEnvironment недоступен.

Ответ 3

Чтобы следить за этим, на случай, если кто-то снова столкнется с одной и той же проблемой, также может случиться так, что по какой-либо причине одно из ваших развертываний застряло в вычислительном эмуляторе.

Что со мной произошло, так это то, что у меня был веброль, содержащий несколько веб-сайтов, каждый из которых привязан к другому имени хоста. Скажем: localhost и test.localhost. Обычно вы можете получить доступ к ним на localhost: 81 и test.localhost: 81. Однако по какой-то странной причине одно развертывание попало в странное состояние, в котором оно будет указано в эмуляторе вычислений, без отладки Visual Studio, он сказал бы, что "экземпляр роли уничтожен" или что-то в этом роде. В этом развертывании сайтов, развернутых в IIS. Затем я, не зная об этом отказоустойчивом развертывании, обращался к URL-адресам по умолчанию, т.е. test.localhost: 81, который будет загружать старые файлы развертывания. (Старый) сайт работал до тех пор, пока я не открыл страницу, которая фактически использовала метод RoleEnvironment.GetConfigurationSettingValue, и только после этого я получил это исключение. Это было очень неприятно, так как это развертывание boggus obvioulsy не ударило ни о каких контрольных точках и не сломалось на исключениях, но оно выглядело точно как сайт, над которым я работал.

Когда я это понял, я открыл имена хостов под новым портом, и там страницы работали, как ожидалось. Как только я удалил это баггированное развертывание из эмулятора вычислений, веб-сайты IIS также были удалены, и, к счастью, порты теперь доступны для использования, как ожидалось.

Ответ 4

Если вы получаете ту же ошибку после того, как убедитесь, что вы используете dev-ткань, попробуйте уменьшить количество экземпляров до одного. Это исправило это для меня.

Тем не менее, кажется странным, что я не могу отлаживать два экземпляра.

Ответ 5

Хотя многие отмечают, что вы должны работать с dev/Azure, а не с сервером разработки asp.net, я думаю, стоит упомянуть, что вам нужно выбрать правильную модель исполнения, когда вы публикуете свои приложение к Azure, если вы хотите использовать RoleEnvironment.

На данный момент существует 3 модели:

VM
Веб-сайт
Служба облачных вычислений

Подробнее см. здесь http://azure.microsoft.com/en-us/documentation/articles/fundamentals-application-models.

И особенно следующий абзац:

Облачные службы, которые были исходной моделью выполнения, предоставленной Azure, является явно PaaS-подходом. В то время как линия между PaaS и веб-хостинг размыт, облачные сервисы отличаются несколькими важными способами с веб-сайтов, включая следующие:

В отличие от веб-сайтов, облачные службы предоставляют административный доступ к вашим виртуальным машинам приложений. Это позволяет установить произвольное программное обеспечение, которое требуется вашему приложению, что невозможно с веб-сайтами.

Поскольку Cloud Services предлагает как веб-роли, так и рабочие роли, это лучший выбор, чем веб-сайты для многоуровневых приложений, для которых требуется отдельная виртуальная машина для своей бизнес-логики.

Облачные службы предоставляют отдельные среды промежуточной и производственной среды, делая обновления приложений более плавными, чем веб-сайты.

В отличие от веб-сайтов, вы можете использовать сетевые технологии, такие как Azure Virtual Network и Azure Connect, для подключения локальных компьютеров к приложениям облачных служб.

Облачные службы позволяют использовать удаленный рабочий стол для непосредственного подключения к виртуальным машинам приложений, что невозможно с веб-сайтами.

Вы можете проверить RoleEnvironment.IsAvailable. Если оно ложно, ваше приложение не работает с временем выполнения Azure, что означает, что RoleEnvironment не применимо.