Errore di generazione di Visual Studio 2010 - Eccezione da HRESULT: 0x800300FA (STG_E_ABNORMALAPIEXIT))

Question

Recentemente abbiamo migrato il nostro ambiente di sviluppo da VS2008 a VS2010 (Ultimate).

Per una soluzione (per ora tutti i C#, .NET Framework 3.5 e ASP.NET 2.0) che contiene 6 progetti VS l'ha aggiornato automaticamente senza problemi.

I progetti soluzione sono:

1. sito ASP.NET
2. progetto VS2010 distribuzione Web per il sito
3. Web Services Application
4. progetto di distribuzione VS2010 Web sopra per sopra WSA
5. Una classe biblioteca.
6. Un'altra libreria di classi.

Tuttavia, quando costruiamo abbiamo 1 errore:

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

Dopo ricerche ho finalmente rintracciato questo per una voce nel sito ASP.NET config:

Se costruisco con questa linea il problema si verifica:

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

Tuttavia, se io commento e costruire con la seguente riga (senza le credenziali fornite) la soluti su build va bene E quindi modificare il web.config di nuovo al (con le credenziali) sopra il sito funziona bene - le credenziali causano solo un problema per la build.

<identity impersonate="true"/> 

Ora qui è il problema più strano - il Web Services Application costruisce bene con le credenziali fornite - l'errore di generazione si verifica solo per il sito web ASP.NET. Tutto ciò è vero se i progetti vengono creati singolarmente o se la soluzione viene ricostruita.

Qualsiasi suggerimento su come creare con successo le credenziali fornite sarà molto apprezzato.

Answer 1

Verificare le autorizzazioni dell'utente di rappresentazione.

Dopo aver impostato il flag su falso, <identity impersonate="false"/>, anche per me è venuto in vita. Tuttavia, una volta l'impostazione di nuovo al vero, è costruita bene, ma quando ho caricato il sito, ho ricevuto:

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

Ora questa macchina è su un dominio, e che l'utente è locale, che dovrebbe avere privilegi amministrativi . Quando ho controllato, non è stato così. Sembra che ci sia una politica che re-imposta gli amministratori locali ogni riavvio.

Answer 2

Grazie per la risposta mattdwen - sfortunatamente il tuo suggerimento non ha mai funzionato (i permessi della cartella 'File temporanei ASP.NET' erano corretti) ma ha fornito il suggerimento che mi ha portato (HACK) a risolvere il problema.Dopo aver letto la tua risposta ho provato la seguente che mi ha portato in una direzione diversa:

(1) ho ricostruito con successo la soluzione 3 volte usando <impersonate="true"/>, <identity impersonate="false"/> e <identity impersonate="true" userName="DOMAIN\different-user" password="password"/> (qui "diverso-utente" è un amministratore locale).

(2) Ho quindi modificato il web.config indietro allo <identity impersonate="true" userName="DOMAIN\user" password="password"/> originale e SOLO ricostruito il progetto del sito Web ASP.NET: successo.

Questo mi ha portato a concludere (fortemente suggerito dal messaggio di errore originale) che VS durante la ricostruzione della soluzione non è in grado (per un motivo ancora sconosciuto) di creare una delle librerie di classi o le sue dipendenze con <identity impersonate="true" userName="DOMAIN\user" password="password"/> nell'ASP Progetto di sito Web .NET.

La libreria di classi in questione ha un numero di riferimenti a componenti di terze parti, interpolazioni di Office, ecc. Che per ora richiederebbero troppo tempo per tentare di eliminare uno per uno e scoprire il vero motivo sottostante.

Pertanto, ho temporaneamente implementato l'hack (cringe) per aggiungere l'utente originale agli amministratori locali.

Answer 3

Mi rendo conto che c'è già una risposta accettata, ma per chiunque altro a venire a questa pagina per una ricerca sul codice di errore ....

Rivedere le autorizzazioni dell'utente che si sta cercando di impersonare.

Nella mia situazione, stavo ricevendo solo l'errore sulla mia macchina di sviluppo, piuttosto che sui nostri server di staging o deployment. (Per un po 'ho aggirato il problema rimuovendo il nodo' identity 'da config nel mio ambiente di sviluppo e aggiungendo la riga in post-build quindi non era un problema nessuno tranne me ..

Nel mio ambiente abbiamo un utente specifico che impersona tutte le nostre app Web durante l'esecuzione. Avevo creato l'account utente, ma non avevo impostato in modo esplicito le autorizzazioni dell'account. Quando ho aggiunto l'utente come amministratore sul mio computer di sviluppo, questo problema è andato via completamente. (Non ideale, lo so, ma "funziona per me" e ha un danno minimo poiché quell'account utente è bloccato sui nostri server "reali" comunque ..)

Answer 4

dopo aver modificato le autorizzazioni su "File ASP.NET temporanei "è necessario eliminare il suo contenuto e consentire ai nuovi file di ereditare le nuove autorizzazioni di sicurezza

Answer 5

Se una delle soluzioni menzionate in precedenza non ha funzionato e si sta utilizzando la rappresentazione. La risposta è di dare il permesso per l'utente che si sta impersonando l'accesso alle seguenti cartelle:

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

2. Tua Directory sito.

anche potrebbe essere necessario creare la cartella come il seguente:

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

Ma provate il primo precedente, ha funzionato per me.

Questi due cambiamenti per concedere l'autorizzazione utente rappresentato per essere in grado di salvare i dati temporanei, e tirare le file dll, e tutti i file necessari dalle directory