Ошибка сборки Visual Studio 2010 - исключение из HRESULT: 0x800300FA (STG_E_ABNORMALAPIEXIT)) - PullRequest
12 голосов
/ 07 июня 2011

Недавно мы перенесли нашу среду разработки с VS2008 на VS2010 (Ultimate).

Для одного решения (на данный момент все C #, .NET Framework 3.5 и ASP.NET 2.0), которое содержит 6 проектов VS, автоматически обновило его без каких-либо проблем.

Проекты решения:

  1. Веб-сайт ASP.NET
  2. Проект веб-развертывания VS2010 для вышеуказанного сайта
  3. Приложение веб-служб
  4. Проект веб-развертывания VS2010 для вышеуказанного WSA
  5. Библиотека классов.
  6. Другая библиотека классов.

Однако, когда мы строим, мы имеем 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. Это все верно, независимо от того, создаются ли проекты индивидуально или решение перестраивается.

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

Ответы [ 5 ]

12 голосов
/ 28 июня 2011

Проверьте права доступа пользователя для олицетворения.

После установки флага в false, <identity impersonate="false"/>, он также ожил для меня.Однако, однажды установив его обратно в true, он работал нормально, но когда я загрузил сайт, я получил:

Текущий идентификатор (XN-DTDEV \ Fusion) не имеет доступа для записи в 'C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ Временные файлы ASP.NET '.

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

4 голосов
/ 22 ноября 2011

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

Просмотрите разрешения пользователя, которого вы пытаетесь выдать.

В моей ситуации я получал ошибку только на моей машине для разработки, а не на наших серверах промежуточного хранения или развертывания.(Некоторое время я справлялся с этим, удаляя узел «identity» из config в моей среде dev и просто добавляя строку в post-build, чтобы не было проблем ни с кем, кроме меня ..

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

1 голос
/ 17 июля 2012

после изменения разрешений для «Временных файлов ASP.NET» необходимо удалить его содержимое и позволить новым файлам наследовать новые разрешения безопасности

0 голосов
/ 06 февраля 2018

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

  1. C:\Windows\Microsoft.NET\Framework[v4.0.30319 or the version that you're using]\Temporary ASP.NET Files

  2. Каталог вашего сайта.

Также вам может понадобиться создать папку следующим образом:

C:\Windows\Microsoft.NET\Framework\[v4.0.30319 or the version that you're using]\Temporary ASP.NET Files\[Application-Name-Goes-Here]

Но попробуйте сначала сначала, у меня это сработало.

Эти два изменения для предоставления олицетворенному пользователю разрешения сохранять временные данные и извлекать файлы dll и все необходимые файлы из каталогов

0 голосов
/ 28 июня 2011

Спасибо за ответ 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) для добавления исходного пользователя к локальным администраторам.

...