Error de compilación de Visual Studio 2010 - Excepción de HRESULT: 0x800300FA (STG_E_ABNORMALAPIEXIT))

Question

Recientemente migramos nuestro entorno de desarrollo de VS2008 a VS2010 (Ultimate).

Para una solución (por ahora todos C#, .NET Framework 3.5 y ASP.NET 2.0) que contiene 6 proyectos VS, se actualizó automáticamente sin ningún problema.

Los proyectos de solución son:

1. página web ASP.NET
2. proyecto de implementación web VS2010 para el sitio por encima de
3. Aplicación de servicios Web
4. proyecto de implementación web VS2010 para arriba WSA
5. Una clase biblioteca.
6. Otra biblioteca de clases.

Sin embargo, cuando construimos tenemos 1 error:

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

Después de una investigación que finalmente rastreado esto a una entrada en la página web ASP.NET config:

Si construyo con esta línea el problema se produce:

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

sin embargo, si comento hacia fuera y construir con la siguiente línea (sin las credenciales suministradas) la soluti en compilaciones finas Y luego modifique el archivo web.config de nuevo al anterior (con las credenciales) el sitio funciona correctamente - las credenciales solo causan un problema para la compilación.

<identity impersonate="true"/> 

Ahora aquí es la cuestión más extraña - la Aplicación de servicios Web construye muy bien con las credenciales suministradas - el error de compilación se produce sólo para el sitio web de ASP.NET. Todo esto es cierto ya sea que los proyectos se construyan individualmente o la solución se reconstruya.

Cualquier puntero sobre cómo puedo construir correctamente con las credenciales proporcionadas será muy apreciado.

Answer 1

Compruebe los permisos del usuario de suplantación.

Después de establecer la bandera en falso, <identity impersonate="false"/>, también cobró vida para mí. Sin embargo, una vez que el establecimiento de nuevo a la verdad, se construyeron bien, pero cuando me carga el sitio, que tiene:

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

Ahora esta máquina está en un dominio, y que el usuario es local, que debe tener privilegios administrativos . Cuando regresé, no fue así. Parece que hay una política de reajuste de los administradores locales cada reinicio.

Answer 2

Gracias por la respuesta mattdwen - desafortunadamente su sugerencia nunca funcionó (los permisos de la carpeta 'Archivos temporales ASP.NET' eran correctos) pero proporcionaron la pista que me condujo a resolver el problema (HACK).Después de leer su respuesta He intentado lo siguiente que me llevó en una dirección diferente:

(1) I reconstruyó con éxito la solución 3 veces usando <impersonate="true"/>, <identity impersonate="false"/> y <identity impersonate="true" userName="DOMAIN\different-user" password="password"/> (en este caso "diferente por el usuario" es un administrador local).

(2) Luego modifiqué el web.config nuevamente al original <identity impersonate="true" userName="DOMAIN\user" password="password"/> y SÓLO reconstruí el proyecto de sitio web ASP.NET - éxito.

Esto me ha llevado a concluir (fuertemente insinuado por el mensaje de error original) que VS al reconstruir la solución no puede (por razones desconocidas) construir una de las bibliotecas de clase o sus dependencias con <identity impersonate="true" userName="DOMAIN\user" password="password"/> en la ASP Proyecto de sitio web .NET.

La Biblioteca de clases en cuestión tiene una serie de referencias a componentes de terceros, interoperabilidad de Office, etc. que por ahora sería una pérdida de tiempo intentar eliminar uno por uno y descubrir el verdadero motivo subyacente.

Por lo tanto, he implementado temporalmente el hack (cringe) para agregar el usuario original a los administradores locales.

Answer 3

me di cuenta que ya hay una respuesta aceptada, pero para cualquier otra persona que viene a esta página mediante una búsqueda en el código de error ....

revisión de los permisos del usuario que está tratando de hacerse pasar.

En mi situación, solo recibía el error en mi máquina de desarrollo, en lugar de hacerlo en nuestros servidores de instalación o distribución. (Durante un tiempo resolví eliminando el nodo 'identidad' de la configuración en mi entorno de desarrollo y simplemente agregué la línea en la creación posterior para que no fuera un problema para nadie más que yo ...

En mi entorno tenemos un usuario específico que todas nuestras aplicaciones web suplantan al ejecutar. Creé la cuenta de usuario, pero no establecí explícitamente los permisos de su cuenta. Cuando agregué el usuario como administrador en mi máquina de desarrollo, este problema desapareció por completo. (No es ideal, lo sé, pero "funciona para mí" y tiene un daño mínimo ya que esa cuenta de usuario está bloqueada en nuestros servidores "reales" de todos modos ...)

Answer 4

después de cambiar los permisos en "Archivos temporales ASP.NET" "debe eliminar su contenido y permitir que los nuevos archivos hereden los nuevos permisos de seguridad

Answer 5

Si alguna de las soluciones mencionadas anteriormente no funcionó, y está utilizando la suplantación de identidad. La respuesta es dar permiso para que el usuario que está suplantando el acceso a las carpetas siguientes:

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

2. Su Directorio de sitio.

también puede que tenga que crear la carpeta de la siguiente manera:

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

Pero trata de la primera anterior, que trabajó para mí.

Esos dos cambios para conceder el permiso de usuario representado para poder guardar los datos temporales, y tirar de los archivos DLL y los archivos necesarios desde los directorios