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

У меня была такая же проблема, но в конечном итоге я смог запустить ее после отклонения 2 или 3 из

«Запуск экземпляров роли занимает больше времени, чем ожидалось»

ящики сообщений.

Затем я обнаружил, что проблема, по-видимому, заключалась в том, что диагностика была включена, а учетная запись хранения была настроена на что-то недопустимое в конфигурации роли (.cscfg).
Решил ее, зайдя в пользовательский интерфейс и отключив диагностику, я обнаружил, что беги нормально.

Чтобы открыть пользовательский интерфейс, щелкните правой кнопкой мыши созданную роль в папке Роли в Обозревателе решений.

Затем я снова включил диагностику, и она автоматически заполнила «UseDevelopmentStorage = true», и это, похоже, работает нормально.

Насколько я понимаю, есть несколько разных вещей, которые могут вызвать эту проблему.

Что касается меня, я столкнулся с этой ошибкой после того, как создал задачу запуска Windows Identity Foundation для своего развертывания Azure, а затем попытался запустить свое приложение с помощью эмулятора Azure.

По сути, все, что мне нужно было сделать, это изменить taskType задачи запуска с simple на background.

ServiceDefinition.csdef

<Startup>
  <Task commandLine="Startup\IdentityGac.cmd" executionContext="elevated" taskType="background"></Task>
</Startup>

Основываясь на вашем вопросе, я не уверен, относится ли это к вашему проекту, но я решил, что, по крайней мере, стоит упомянуть.

Вы можете прочитать мою полную запись в блоге здесь.

Новая причина этой проблемы была введена в феврале 2016 года.

Использование Windows 8.1, Visual Studio 2012 с обновлением 5 и эмулятора Azure 2.3.

Установка этого обновления Windows: KB3126593 оставит вас в ситуации, когда эмулятор никогда start, и вы увидите это в пользовательском интерфейсе эмулятора.

Удаление обновления исправляет эмулятор.

Панель управления> Все элементы панели управления> Программы и компоненты> Установленные обновления

Обновление безопасности для Microsoft Windows (KB3126593), щелкните правой кнопкой мыши, удалите.

(Обновление до Windows 10 также решает проблему.)

Я также столкнулся с той же проблемой. Изучив пользовательский интерфейс эмулятора, я обнаружил, что он пытается прочитать некоторую дату из области хранения и терпит неудачу.
Итак, что я сделал, я пошел в папку %appdata%\local и удалил все данные из папок
1. DevelopmentStorage
2. dftmp

После перезапуска службы все заработало.

Для меня проблема была связана с кэшированием. Проблема началась с предупреждения, в котором говорилось что-то вроде «невозможно установить кеш.... exe», но я видел ошибку только один раз. После этого эмулятор каждый раз зависал. После прочтения этого блога Я попытался отключить, а затем снова включить кэширование, что решило проблему.

После дальнейшего расследования я обнаружил, что критической проблемой была эта запись в ServiceConfiguration.Local.cscfg:

      <Setting name="Microsoft.WindowsAzure.Plugins.Caching.ConfigStoreConnectionString" value="UseDevelopmentStorage=true" />

Ранее эта строка подключения указывала на подключение к облачному хранилищу.

По моему опыту, это может произойти, если одна из ваших ролей не останавливается при вызове OnStop(). Ищите WaWorkerHost.exe (я думаю). Вы также можете попробовать убить IisConfigurator.exe (или что-то в этом роде). Вы знаете, что у вас правильный процесс, когда ваш список диспетчера задач становится значительно короче :-)

Я столкнулся с той же проблемой и обнаружил, что следующие шаги решили ее (я наткнулся на это решение, применив ответ от @RobPotter выше).

Сначала откройте файл ServiceDefinition.csdef и добавьте следующую запись:

<Import moduleName="Diagnostics" />

К узлу ServiceDefinition/WebRole/Imports.

Во-вторых, добавьте следующий параметр конфигурации диагностики в необходимые файлы .cscfg:

<Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="UseDevelopmentStorage=true" />

в разделе: ServiceConfiguration / Role / ConfigurationSettings для веб-роли.

к вашему сведению. Мое значение определения службы для schemaVersion — «2012-10.1.8». Проблема могла возникнуть, когда я перенес свое решение с SDK 1.7 на 1.8.

Я не могу решить проблему после того, как выполнил все приведенные выше решения. Наконец, я решил больше не позволять этому останавливать мое кодирование, просто изменил проект StartUp с «Облачный проект» на «Проект WebRole» и F5, ... ОК, веб-сайт работает правильно на моем IIS Express.

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

(у меня AzureSDK версии 2.0)

Аналогично ответам выше. Я запускал сценарий запуска, и он запускал appcmd.exe, однако из-за ошибки раздел, который я пытался разблокировать, вызвал ошибку, из-за которой роли не запускались.

Я использовал:

%windir%\System32\inetsrv\appcmd.exe конфигурация разблокировки /section:system.webServer/security

но это ошибка и должно было быть

%windir%\System32\inetsrv\appcmd.exe конфигурация разблокировки /section:system.webServer/security/access

Для меня это произошло только тогда, когда у меня был установлен флажок «Включить кэширование». И для меня проблема заключалась в том, что я запускал свой проект с общего ресурса UNC (на самом деле он работал на виртуальной машине на моем macbook). Когда я запускал отладчик после установки флажка «Включить кэширование» в рабочей роли, он просто зависал. Приходите, чтобы узнать, примерно каждые 2 секунды он создавал файл дампа размером 160 МБ в C:\Windows\System32\%LOCALAPPDATA%\CrashDumps. После отладки одного из них я увидел, что первая ошибка была, когда он пытался запустить cmd.exe для кэширования в моей рабочей роли, и он сказал, что CMD не может быть запущен на сетевом ресурсе, поэтому по умолчанию он будет использовать windows/system32 или что-нибудь.

Именно тогда я нашел эту удобную статью MS KB 7-летней давности: http://support.microsoft.com/kb/156276 Когда я добавил DisableUNCCheck REG_DWORD и установил значение 0 x 1 (Hex) в пути реестра HKEY_CURRENT_USER\Software\Microsoft\Command Processor, все запустилось как положено. Надеюсь, это поможет кому-то другому.

Я столкнулся с той же проблемой и провел много часов, включая проверку всех остальных ответов на этот пост. Я просто удаляю свое приложение под ролями и снова добавляю проект webrole в текущее решение. И работает нормально для меня.

У меня была аналогичная проблема. Я выполнял файл .cmd для регистрации зависимой библиотеки DLL во время начала сеанса отладки. Файл .CSDEF выглядит так:

<ServiceDefinition name="WorkerRole.Azure" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition" schemaVersion="2014-06.2.4">
    <WorkerRole name="SampleWorkerRole" vmsize="Small">
         <Startup>
               <Task commandLine="register.cmd" executionContext="elevated" taskType="simple" />
         </Startup>
     </WorkerRole>
</ServiceDefinition>

После запуска Visual Studio с использованием параметра «Запуск от имени администратора» эта проблема не возникала. я смог отладить приложение, как обычно.

Моя среда: Windows Service 2012 R2 + VS 2013 Update 3 + Azure Tools 2.2

У меня работает удаление обновления Windows KB3126593!!!