Блог

Я пытаюсь вызвать 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.Службы взаимодействия.Исключение SEHException: внешний компонент выдал исключение.

[Исключение SEHException (0x80004005): внешний компонент выдал исключение.] RoleEnvironmentGetConfigurationSettingValueW(UInt16 * , UInt16 * , UInt32, UInt32 * ) 0 Microsoft.WindowsAzure.ServiceRuntime.Внутреннее.InteropRoleManager.GetConfigurationSetting(имя строки, строка и ret) 92 Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.GetConfigurationSettingValue(строковое имя_конфигурации_установки) 67 ChargifyNET.ChargifyAzurePage.get_Chargify() в C:NetProjectsChargifyDotNETSourceChargify.NETChargifyAzurePage.cs:26 Взимать плату.Azure._Default.Page_Load(отправитель объекта, EventArgs e) в C:NetProjectsChargifyDotNETSourceChargify .AzureDefault.aspx.vb:8 System.Web.UI.Control.OnLoad(EventArgs e) 99 System.Web.UI.Control.LoadRecursive() 50 System.Web.UI.Page.ProcessRequestMain(Логическое значение includeStagesBeforeAsyncPoint, логическое значение includeStagesAfterAsyncPoint) 627

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

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

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

Удаление <Sites> тега в ServiceDefinition.csdef файле может быть обходным решением для вас, как и для нас, но тогда ваш сайт не будет полностью развернут в IIS в облаке. Мы используем 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> узел и разверните, и вы можете обнаружить это сейчас RoleEnvironment.IsAvailable = True .

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

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

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

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

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

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

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

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

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

• Виртуальная машина
• Веб-сайт
• Облачный сервис

Пожалуйста, обратитесь сюда: http://azure.microsoft.com/en-us/documentation/articles/fundamentals-application-models для получения более подробной информации.

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

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

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

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