Błąd kompilacji Visual Studio 2010 - Wyjątek od HRESULT: 0x800300FA (STG_E_ABNORMALAPIEXIT))

Question

Niedawno przeprowadziliśmy migrację naszego środowiska programistycznego z VS2008 do VS2010 (Ultimate).

Dla jednego rozwiązania (na razie wszystkie C#, .NET Framework 3.5 i ASP.NET 2.0), który zawiera 6 projektów, VS automatycznie uaktualnił go bez żadnych problemów.

Projekty rozwiązania są:

1. strona ASP.NET
2. projekt VS2010 Web Deployment dla wyżej podanej stronie
projektu Wdrożenie
3. Web Services Application
4. VS2010 Web dla powyższego WSA
5. klasy A biblioteka.
6. Kolejna biblioteka klas.

Jednak, gdy budujemy mamy 1 błąd:

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)) 

Po badaniach I wreszcie śledzone tego jednego wpisu w ASP.NET strony config:

Gdybym budować z tej linii problem występuje:

<identity impersonate="true" userName="DOMAIN\user" password="password"/> 

Jednakże, jeśli skomentuję i zbuduję za pomocą poniższej linii (bez podanych poświadczeń), soluti na kompilacji dobrze, a następnie zmień web.config z powrotem na powyższy (z poświadczeniami) witryna działa dobrze - poświadczenia powodują tylko problem dla kompilacji.

<identity impersonate="true"/> 

Teraz tutaj jest najdziwniejszy problem - w Web Services Application buduje dobrze z podanych parametrów - błąd kompilacji występuje tylko na stronie ASP.NET. To wszystko sprawdza się niezależnie od tego, czy projekty są budowane indywidualnie, czy też rozwiązanie zostało przebudowane.

Wszelkie wskazówki, w jaki sposób mogę z powodzeniem budować za pomocą dostarczonych poświadczeń, będą bardzo mile widziane.

Answer 1

Sprawdź uprawnienia użytkownika podszywania się.

Po ustawieniu flagi na wartość false, <identity impersonate="false"/>, również ożyło. Jednak po ustawieniu go na true, zbudowana w porządku, ale kiedy załadować stronę, mam:

The current identity (XN-DTDEV\Fusion) does not have write access to 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files'.

Teraz ta maszyna znajduje się w domenie, a użytkownik jest lokalna, która powinna mieć uprawnienia administratora . Kiedy się sprawdziłem, nie było. Wygląda na to, że istnieje polityka ponownego ustawienia administratorów lokalnych przy każdym ponownym uruchomieniu systemu.

Answer 2

Dzięki za odpowiedź mattdwen - niestety Twoja sugestia nigdy nie zadziałała (uprawnienia folderu "Tymczasowe pliki ASP.NET" były poprawne), ale dostarczyły wskazówki, która doprowadziła mnie (HACK) do rozwiązania problemu.Po przeczytaniu odpowiedź Próbowałem następujących składników, które doprowadziły mnie w innym kierunku:

(1) pomyślnie odbudował Rozwiązanie 3 razy stosując <impersonate="true"/>, <identity impersonate="false"/> i <identity impersonate="true" userName="DOMAIN\different-user" password="password"/> (tutaj „inny użytkownik” jest lokalnym admin).

(2) Następnie zmieniłem web.config z powrotem na oryginalny <identity impersonate="true" userName="DOMAIN\user" password="password"/> i TYLKO przebudowałem projekt strony ASP.NET - sukces.

To doprowadziło mnie do wniosku (wyraźnie zasygnalizowanego oryginalnym komunikatem o błędzie), że VS podczas przebudowy rozwiązania nie jest w stanie (z nieznanego dotąd powodu) zbudować jednej z bibliotek klas lub jej zależności z <identity impersonate="true" userName="DOMAIN\user" password="password"/> w ASP Projekt witryny .NET.

Biblioteka klas, o której mowa, ma wiele odniesień do komponentów innych firm, interfejsów Office itp., Które na razie byłyby zbyt czasochłonne, aby spróbować wyeliminować jeden po drugim i odkryć prawdziwy podstawowy powód.

Dlatego tymczasowo zaimplementowałem hack (cringe), aby dodać oryginalnego użytkownika do lokalnych administratorów.

Answer 3

Zdaję sobie sprawę, że to już zaakceptowane odpowiedź, ale dla nikogo nadchodzący do tej strony za pośrednictwem wyszukiwarki na kod błędu ....

Przejrzyj uprawnienia użytkownika, który starasz się podszyć.

W mojej sytuacji dostałem błąd tylko na mojej maszynie programistycznej, a następnie na naszych serwerach pomostowych lub wdrożeniowych. (Przez chwilę obejrzałem to, usuwając węzeł "tożsamość" z konfiguracji w moim środowisku deweloperskim i po prostu dodając wiersz w postprodukcji, więc nie był to problem nikomu innemu niż ja ..

W moim środowisku mamy określonego użytkownika, że ​​wszystkie nasze aplikacje są podrabiane po uruchomieniu - utworzyłem konto użytkownika, ale nie ustawiłem jawnie jego uprawnień do konta. Gdy dodałem użytkownika jako administratora na moim komputerze, ten problem całkowicie zniknął. (Nie jest to idealne, wiem, ale to "działa dla mnie" i ma minimalną szkodę, ponieważ to konto użytkownika jest i tak zablokowane na naszych "prawdziwych" serwerach).

Answer 4

po zmianie uprawnień do "Tymczasowych plików ASP.NET "musisz usunąć jego zawartość i zezwolić nowym plikom na dziedziczenie nowych uprawnień zabezpieczeń

Answer 5

Jeśli którekolwiek z wymienionych rozwiązań nie zadziałało i używasz personifikacji. Odpowiedź jest przekazanie uprawnienia dla użytkownika, że ​​jesteś podszywania dostęp do następujących folderów:

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

2. Twój katalog site.

też może trzeba utworzyć folder, jak następuje:

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

Ale spróbuj poprzedni najpierw pracował dla mnie.

Te dwie zmiany przyznawania personifikowanego uprawnienia użytkownika, aby móc zapisać dane tymczasowe, i ciągnąć dll i wszelkie potrzebne pliki z katalogów