Erreur Visual Studio 2010 Build - Exception de HRESULT: 0x800300FA (STG_E_ABNORMALAPIEXIT))

Question

Récemment, nous avons migré notre environnement de développement de VS2008 à VS2010 (Ultimate).

Pour une solution (pour l'instant tout C#, .NET Framework 3.5 et ASP.NET 2.0) qui contient 6 projets VS mis à jour automatiquement sans aucun problème.

Les projets de solution sont:

1. site ASP.NET
2. projet VS2010 Web de déploiement pour le site ci-dessus
3. application de services Web
4. projet de déploiement Web VS2010 pour ci-dessus WSA
5. Une classe bibliothèque.
6. Une autre bibliothèque de classes.

Cependant, lorsque nous construisons nous avons 1 erreur:

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

Après recherches, je finalement pisté ce à une entrée dans la configuration du site ASP.NET:

Si je construis avec cette ligne le problème se produit:

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

Cependant, si je commente et construis avec la ligne suivante (sans les informations d'identification fournies), la soluti sur construit bien et puis modifier le web.config retour à ce qui précède (avec les informations d'identification) le site fonctionne bien - les informations d'identification ne provoquent un problème pour la construction.

<identity impersonate="true"/> 

Maintenant, voici le plus étrange question - l'application de services Web se construit bien avec les informations d'identification fournies - l'erreur de compilation se produit uniquement pour le site Web ASP.NET. Tout cela est vrai que les projets soient construits individuellement ou que la solution soit reconstruite.

Tous les pointeurs que je peux construire avec succès avec les informations d'identification fournies seront grandement appréciés.

Answer 1

Vérifiez les autorisations de l'utilisateur d'usurpation d'identité. Après avoir simplement mis le drapeau à false, <identity impersonate="false"/>, ça a aussi pris vie pour moi. Cependant, la mise une fois de retour à vrai, il construit bien, mais quand je charge le site, je me suis:

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

Maintenant, cette machine est sur un domaine, et que l'utilisateur est local, ce qui devrait avoir des privilèges d'administrateur . Quand je suis revenu, ce n'était pas le cas. Il semble qu'il y ait une politique redéfinissant les administrateurs locaux à chaque redémarrage.

Answer 2

Merci pour la réponse mattdwen - malheureusement, votre suggestion n'a jamais fonctionné (les permissions du dossier 'Temporary ASP.NET Files' étaient correctes) mais a fourni l'indice qui m'a conduit à résoudre le problème.Après avoir lu votre réponse j'ai essayé ceci qui m'a conduit dans une autre direction:

(1) Je reconstruit avec succès la solution 3 fois à l'aide <impersonate="true"/>, <identity impersonate="false"/> et <identity impersonate="true" userName="DOMAIN\different-user" password="password"/> (ici « différents utilisateurs » est un administrateur local).

(2) J'ai ensuite modifié le fichier web.config pour retourner à <identity impersonate="true" userName="DOMAIN\user" password="password"/> d'origine et reconstruire SEULEMENT le projet de site Web ASP.NET - succès. Cela m'a conduit à conclure (fortement suggéré par le message d'erreur original) que VS lors de la reconstruction de la solution est incapable (pour une raison inconnue) de construire l'une des bibliothèques de classes ou ses dépendances avec <identity impersonate="true" userName="DOMAIN\user" password="password"/> dans l'ASP Projet de site Web .NET.

La bibliothèque de classes en question contient un certain nombre de références à des composants tiers, Office Interops, etc. qui, pour le moment, prendrait trop de temps à essayer d'éliminer un par un et de découvrir la véritable raison sous-jacente.

Par conséquent, j'ai temporairement mis en œuvre le hack (cringe) pour ajouter l'utilisateur d'origine aux administrateurs locaux.

Answer 3

Je me rends compte qu'il ya déjà une réponse acceptée, mais pour ceux qui viennent d'autre à cette page via une recherche sur le code d'erreur ....

Passez en revue les autorisations de l'utilisateur que vous essayez d'usurper l'identité. Dans ma situation, je recevais seulement l'erreur sur mon ordinateur de développement, plutôt que sur nos serveurs de transfert ou de mise en scène. (Pendant un moment je me suis débrouillé en supprimant le noeud 'identity' de config dans mon environnement de développement et en ajoutant simplement la ligne en post-build donc ce n'était pas un problème autre que moi ..

Dans mon environnement J'ai créé un compte d'utilisateur, mais je n'avais pas explicitement défini les permissions de mon compte, quand j'ai ajouté l'utilisateur en tant qu'administrateur sur ma machine dev, ce problème est parti complètement. (Pas idéal, je sais, mais ça "marche pour moi", et a un minimum de mal puisque ce compte d'utilisateur est verrouillé sur nos 'vrais' serveurs de toute façon ..)

Answer 4

après avoir changé les permissions sur "Fichiers ASP.NET temporaires" "vous devez supprimer son contenu et autoriser les nouveaux fichiers à hériter des nouvelles autorisations de sécurité

Answer 5

Si l'une des solutions mentionnées précédemment ne fonctionnait pas, et que vous utilisez une usurpation d'identité. La réponse est de donner l'autorisation pour l'utilisateur que vous faisant passer pour l'accès aux dossiers suivants:

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

2. Votre Annuaire site.

aussi vous pourriez avoir besoin de créer le dossier comme suit:

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

Mais essayez la première précédente, il a travaillé pour moi.

Ces deux changements d'octroi de l'autorisation de l'utilisateur personnifié pour être en mesure d'enregistrer les données temporaires, et tirez les fichiers dll, et tous les fichiers nécessaires à partir des répertoires