Ошибка сборки Visual Studio 2010 - исключение из HRESULT: 0x800300FA (STG_E_ABNORMALAPIEXIT))
Недавно мы перенесли нашу среду разработки с VS2008 на VS2010 (Ultimate).
Для одного решения (на данный момент все С#,.NET Framework 3.5 и ASP.NET 2.0), который содержит 6 проектов, VS автоматически обновил его без каких-либо проблем.
Проекты решений:
- Веб-сайт ASP.NET
- Проект VS2010 для веб-развертывания для сайта
- Приложение веб-служб
- Проект VS2010 для веб-развертывания для WSA
- Библиотека классов.
- Другая библиотека классов.
Однако при построении мы имеем 1 ошибку:
Could not load file or assembly 'ClassLibrary1BLL, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An API call exited abnormally. (Exception from HRESULT: 0x800300FA (STG_E_ABNORMALAPIEXIT))
После исследования я, наконец, отследил это до одной записи в конфигурации веб-сайта ASP.NET:
Если я строю с этой строкой, возникает проблема:
<identity impersonate="true" userName="DOMAIN\user" password="password"/>
Однако, если я прокомментирую и построю следующую строку (без предоставленных учетных данных), решение строит штраф И затем измените файл web.config на вышеупомянутое (с учетными данными), сайт работает нормально - только учетные данные проблема для сборки.
<identity impersonate="true"/>
Теперь вот самая странная проблема - приложение веб-сервисов строит отлично с предоставленными учетными данными - ошибка сборки возникает ТОЛЬКО для веб-сайта ASP.NET. Все это верно, независимо от того, построены ли проекты по отдельности или реконструировано решение.
Будут оценены любые указатели, как я могу успешно построить с предоставленными учетными данными.
Ответы
Ответ 1
Проверьте разрешения пользователя олицетворения.
После того, как флаг установлен на false, <identity impersonate="false"/>
, он также ожил для меня.
Однако, вернув его в true, он построил отлично, но когда я загрузил сайт, я получил:
Текущее тождество (XN-DTDEV\Fusion) не имеет доступа для записи "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary Файлы ASP.NET.
Теперь этот компьютер находится в домене, и этот пользователь является локальным, у которого должны быть административные привилегии. Когда я вернулся, это не так. Похоже, что при каждой перезагрузке политики перезагружаются локальные администраторы.
Ответ 2
Я понимаю, что есть уже принятый ответ, но для других, кто приходит на эту страницу через поиск по коду ошибки....
Просмотрите разрешения пользователя, который вы пытаетесь выдавать себя за него.
В моей ситуации я получал ошибку только на своей машине разработки, а не на наших серверах развертывания или развертывания. (Некоторое время я обошел это, удалив "identity" node из config в моей среде dev и просто добавив строку в post-build, поэтому это не проблема никого, кроме меня.
В моей среде у нас есть определенный пользователь, который все наши веб-приложения олицетворяют при запуске. Я создал учетную запись пользователя, но явным образом не установил ее разрешения для учетной записи. Когда я добавил пользователя в качестве администратора на моей машине dev, эта проблема полностью исчезла. (Не идеально, я знаю, но он "работает для меня" и имеет минимальный вред, так как эта учетная запись пользователя заблокирована на наших "настоящих" серверах в любом случае..)
Ответ 3
после изменения разрешений на "Временные файлы ASP.NET" вам необходимо удалить его содержимое и разрешить новым файлам наследовать новые разрешения безопасности
Ответ 4
Спасибо за ответ mattdwen - к сожалению, ваше предложение никогда не срабатывало (права на папку "Временные файлы ASP.NET" были правильными), но предоставили подсказку, которая приведет меня (HACK) к решению проблемы. Прочитав ваш ответ, я попробовал следующее, что привело меня в другом направлении:
(1) Я успешно восстановил решение 3 раза, используя <impersonate="true"/>
, <identity impersonate="false"/>
и <identity impersonate="true" userName="DOMAIN\different-user" password="password"/>
(здесь "другой пользователь" является локальным администратором).
(2) Затем я изменил web.config на исходный <identity impersonate="true" userName="DOMAIN\user" password="password"/>
и ТОЛЬКО перестроил проект веб-сайта ASP.NET - успех.
Это привело меня к выводу (сильно намекнув исходное сообщение об ошибке), что VS при восстановлении решения не может (по неизвестной причине) построить один из библиотек классов или его зависимостей с помощью <identity impersonate="true" userName="DOMAIN\user" password="password"/>
в Проект веб-сайта ASP.NET.
В рассматриваемой библиотеке классов имеется ряд ссылок на сторонние компоненты, межсетевые экраны Office и т.д., которые в настоящее время будут слишком трудоемкими, чтобы попытаться устранить один за другим и обнаружить реальную основную причину.
Поэтому я временно применил хак (cringe), чтобы добавить исходного пользователя к локальным администраторам.
Ответ 5
Если какое-либо из упомянутых выше решений не сработало, и вы используете олицетворение.
Ответ заключается в том, чтобы дать пользователю разрешение на использование следующих папок:
также вам может понадобиться создать папку следующим образом:
C:\Windows\Microsoft.NET\Framework\[v4.0.30319 or the version that you're using]\Temporary ASP.NET Files\[Application-Name-Goes-Here]
Но сначала попробуйте предыдущее, это сработало для меня.
Эти два изменения для предоставления импринтер-пользовательскому разрешению возможности сохранять временные данные и вытаскивать DLL файлы и любые необходимые файлы из каталогов