Блог

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

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

Проекты решений являются:

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="DOMAINuser" password="password"/>
  

Однако, если я закомментирую и выполню сборку со следующей строкой (без предоставленных учетных данных), решение будет выполнено нормально, а затем верну web.config к приведенному выше (с учетными данными), сайт будет работать нормально — учетные данные вызывают проблему только при сборке.

 <identity impersonate="true"/>
  

Теперь вот самая странная проблема — приложение веб-служб нормально создается с предоставленными учетными данными — ошибка сборки возникает ТОЛЬКО для ASP.NET веб-сайт. Все это справедливо независимо от того, создаются ли проекты по отдельности или перестраивается решение.

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

Проверьте разрешения пользователя, выдающего себя за другого.

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

Текущий идентификатор (XN-DTDEV Fusion) не имеет доступа на запись в ‘C:WindowsMicrosoft.NETFramework64v4.0.30319Temporary ASP.NET Файлы’.

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

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

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

В моей ситуации я получал ошибку только на своей машине разработки, а не на наших промежуточных серверах или серверах развертывания. (Некоторое время я обходил это, удаляя узел ‘identity’ из конфигурации в моей среде разработки и просто добавляя строку после сборки, так что это не было проблемой ни для кого, кроме меня..

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

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

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

1. C:WindowsMicrosoft.NETFramework[v4.0.30319 or the version that you're using]Temporary ASP.NET Files

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

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

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

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

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

Спасибо за ответ mattdwen — к сожалению, ваше предложение так и не сработало (‘Временный ASP.NET Права доступа к папкам файлов были правильными), но предоставили подсказку, которая привела ко мне (ВЗЛОМАТЬ) решение проблемы. После прочтения вашего ответа я попробовал следующее, что привело меня в другом направлении:

(1) Я успешно перестроил решение 3 раза, используя <impersonate="true"/> , <identity impersonate="false"/> и <identity impersonate="true" userName="DOMAINdifferent-user" password="password"/> (здесь «другой пользователь» — это локальный администратор).

(2) Затем я вернул web.config к исходному <identity impersonate="true" userName="DOMAINuser" password="password"/> и ТОЛЬКО перестроил ASP.NET проект веб-сайта — успешный.

Это привело меня к выводу (на который сильно намекает исходное сообщение об ошибке), что VS при перестройке решения не может (по пока неизвестной причине) собрать одну из библиотек классов или ее зависимостей с <identity impersonate="true" userName="DOMAINuser" password="password"/> в ASP.NET проект веб-сайта.

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

Поэтому я временно внедрил взлом (cringe), чтобы добавить исходного пользователя к локальным администраторам.