Ролевые экземпляры занимают больше времени, чем ожидалось, - есть ли новое решение этой проблемы?
Я перезагрузил свой компьютер 50-100 раз на этой неделе. Я нахожу, что я могу запускать/развертывать локально обычно 3-4 раза, прежде чем получать это сообщение:
"Средства Windows Azure для Microsoft Visual Studio
Ролевые экземпляры занимают больше времени, чем ожидалось. Вы хотите продолжать ждать? "
Решение о том, чтобы я снова зашел, перезагружается.
Я знаю, что это не новая проблема. Я помню, что MS согласилась, что это проблема, но у кого-то есть решение, которое не связано с возвратом в Hosted Web Core. Похоже, эта проблема - это то, что многие люди получают, и это было вокруг без разрешения (которое я знаю) в течение 4-5 месяцев и более.
Теперь я вернусь к другой перезагрузке!!!!!
Ответы
Ответ 1
У меня была такая же проблема, но в итоге я мог начать ее после отклонения 2 или 3
"Ролевые экземпляры занимают больше времени, чем ожидалось"
.
Затем я обнаружил, что проблема заключается в том, что Диагностика была включена, и учетная запись хранилища была настроена на что-то недопустимое в конфигурации ролей (.cscfg).
Решив его, перейдя в интерфейс и отключив диагностику, я обнаружил, что он будет работать нормально.
Чтобы получить пользовательский интерфейс, щелкните правой кнопкой мыши созданную роль в папке "Роли" в обозревателе решений.
![enter image description here]()
Затем я снова включил диагностику и автоматически заполнил "UseDevelopmentStorage = true", и это, похоже, работает нормально.
Ответ 2
Из того, что я понимаю, есть несколько разных вещей, которые могут вызвать эту проблему.
Для меня я столкнулся с этой ошибкой после создания задачи запуска Windows Identity Foundation для развертывания Azure, а затем попытался запустить приложение с помощью Azure Emulator.
В принципе, все, что мне нужно было сделать, это изменить taskType
Задачи запуска от simple
до background
ServiceDefinition.csdef
<Startup>
<Task commandLine="Startup\IdentityGac.cmd" executionContext="elevated" taskType="background"></Task>
</Startup>
Исходя из вашего вопроса, я не уверен, относится ли это к вашему проекту, но я полагал, что, по крайней мере, стоит упомянуть.
Вы можете прочитать мой полный пост в блоге здесь.
Ответ 3
Новая причина для этой проблемы была введена в феврале 2016 года.
Использование Windows 8.1, Visual Studio 2012 Update 5 и Azure Emulator 2.3
Установка этого обновления для Windows: KB3126593 оставит вас в ситуации, когда эмулятор никогда не запустится, и вы увидите это в интерфейсе эмулятора.
![введите описание изображения здесь]()
Удаление обновления исправляет эмулятор.
Панель управления > Все элементы панели управления > Программы и компоненты > Установленные обновления
Обновление безопасности для Microsoft Windows (KB3126593), щелкните правой кнопкой мыши, удалите.
(Обновление до Windows 10 также решает проблему.)
Ответ 4
Я тоже столкнулся с той же проблемой. От взгляда на интерфейс эмулятора я обнаружил, что он пытался прочесть некоторую дату из области хранения и потерпел неудачу.
Итак, что я сделал, я отправился в папку % appdata%\local и удалил все данные из папок
1. DevelopmentStorage
2. dftmp
После перезапуска службы все начали работать
Ответ 5
Для меня проблема связана с кэшированием. Проблема началась с предупреждения, в котором говорилось что-то вроде "невозможно установить кеш... exe", но я видел ошибку только один раз. После этого эмулятор застопорился каждый раз. После чтения этого блога я попытался отключить, а затем снова включить кеширование, которое устранило проблему.
После некоторого дальнейшего исследования я обнаружил, что критическая проблема была в этой записи в ServiceConfiguration.Local.cscfg:
<Setting name="Microsoft.WindowsAzure.Plugins.Caching.ConfigStoreConnectionString" value="UseDevelopmentStorage=true" />
Ранее эта строка подключения указывала на соединение с облачным хранилищем.
Ответ 6
По моему опыту это может произойти, если одна из ваших ролей не останавливается при вызове OnStop(). Ищите WaWorkerHost.exe(я думаю). Вы также можете попробовать убить IisConfigurator.exe(или что-то в этом роде). Вы знаете, что у вас есть правильный процесс, когда список ваших менеджеров задач становится значительно короче: -)
Ответ 7
Я столкнулся с той же проблемой и обнаружил, что следующие шаги были разрешены (я наткнулся на это решение при применении ответа от @RobPotter выше).
Сначала оставьте файл ServiceDefinition.csdef и добавьте эту запись:
<Import moduleName="Diagnostics" />
К: ServiceDefinition/WebRole/Imports node.
Во-вторых, добавьте следующие настройки конфигурации диагностики в необходимые файлы .cscfg:
<Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="UseDevelopmentStorage=true" />
в разделе: ServiceConfiguration/Role/ConfigurationSettings для веб-роли.
FYI. Значение моей службы определения для schemaVersion - "2012-10.1.8". Возможно, проблема возникла, когда я перенес свое решение с SDK 1.7 до 1.8
Ответ 8
Я не могу решить проблему после всех вышеперечисленных решений.
Наконец, я решил больше не останавливать свою кодировку, просто изменил проект StartUp из "Облачного проекта" в "Проект WebRole", а F5,... OK веб-сайт работает правильно на моем IIS Express.
Итак, я думаю, если он может опубликовать в Azure и может отлаживать веб-сайт на местном уровне, просто дайте ему работать таким образом, пока Microsoft не станет проще использовать.
(мой AzureSDK - 2.0)
Ответ 9
Как и ответы выше. Я запускал запуск script, и он запускал appcmd.exe, однако из-за ошибки раздел, который я пытался разблокировать, вызвал ошибку, из-за которой роли не запускались.
Я использовал:
% windir%\System32\inetsrv\appcmd.exe unlock config/section:system.webServer/security
но это ошибка и должно было быть
% windir%\System32\inetsrv\appcmd.exe unlock config/section:system.webServer/security/access
Ответ 10
Для меня это произошло только тогда, когда был установлен флажок "Включить кэширование". И для меня проблема заключалась в том, что я запускал свой проект из UNC Share (фактически, он работал в VM на моем macbook). Когда я запустил отладчик после проверки поля "Включить кеширование" на роль рабочего, он просто зависает. Приходите, чтобы узнать, примерно каждые 2 секунды он создавал файл дампа в 160 Мбайт в C:\Windows\System32\%LOCALAPPDATA%\CrashDumps. После отладки одного из них я мог видеть, что первая ошибка заключалась в том, что она пыталась запустить cmd.exe в кешировании в моей рабочей роли, и он сказал, что CMD не может быть запущен на сетевом ресурсе, поэтому он будет по умолчанию использовать windows/system32 или что-то.
Что, когда я нашел эту удобную денди 7-летнюю статью MS KB: http://support.microsoft.com/kb/156276 Когда я добавил DisableUNCCheck REG_DWORD
и установил значение 0 x 1 (Hex)
по пути реестра HKEY_CURRENT_USER\Software\Microsoft\Command Processor
все началось точно так же, как чемпион. Надеюсь, это поможет кому-то еще.
Ответ 11
Я столкнулся с той же проблемой и провел много часов, включая проверку всех остальных ответов этого сообщения. Я просто удаляю свое приложение под роли и снова добавляю проект webrole в текущее решение. И отлично работает для меня.
Ответ 12
У меня была аналогичная проблема. Я выполнял файл .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 с использованием опции "Запуск от имени администратора" эта проблема не возникла. Я смог отлаживать приложение как обычно.
Ответ 13
Моя среда:
Windows Service 2012 R2 + VS 2013 Обновление 3 + Azure Tools 2.2
Удалить обновление Windows KB3126593 работает для меня!!!