c# - Las referencias de ensamblaje no se resolverán correctamente en nuestro servidor de compilación

team-build assembly-resolution (7)

Codificamos en C # usando VS2008 SP1. Tenemos un servidor que ejecuta Team System Server 2008 que utilizamos para control de fuente, tareas, etc. El servidor también es nuestra máquina de compilación para Team Build . Esto ha estado funcionando bien durante mucho tiempo. Hasta ahora. Recibimos estos mensajes de error cuando intentamos construir uno de nuestros proyectos que tiene una referencia a un ensamblado externo (esto sucede tanto a través de Team Build, y cuando se inicia sesión físicamente y haciendo una compilación regular a través de Visual Studio):

C: / WINDOWS / Microsoft.NET / Framework / v3.5 / Microsoft.Common.targets: advertencia MSB3246: el archivo resuelto tiene una imagen incorrecta, no hay metadatos o no se puede acceder a él. No se pudo cargar el archivo o ensamblado ''C: / Program Files / Syncfusion / Essential Studio / 7.1.0.21 / Assemblies / 3.5 / Syncfusion.XlsIO.Base.dll'' o una de sus dependencias. Se esperaba que el módulo incluyera un manifiesto de ensamblaje.
C: / Archivos de programa / MSBuild / Microsoft / VisualStudio / v9.0 / ReportingServices / Microsoft.ReportingServices.targets (24,2): error MSB4062: La tarea "Microsoft.Reporting.RdlCompile" no se pudo cargar desde el ensamblado Microsoft. ReportViewer.Common, Version = 9.0.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a. No se pudo cargar el archivo o el ensamblado ''Microsoft.ReportViewer.Common, Version = 9.0.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a'' o una de sus dependencias. Se esperaba que el módulo incluyera un manifiesto de ensamblaje. Confirme que la declaración sea correcta y que el ensamblado y todas sus dependencias estén disponibles.
El componente al que se hace referencia ''Syncfusion.XlsIO.Base'' no se pudo encontrar.

Estos errores son para un proyecto con una referencia de ensamblado problemática. Cuando intento construir la solución completa, hay muchos más errores debido a esta. Y hay otros dos proyectos que tienen el mismo problema con otras referencias de ensamblaje. Tengo una lista de los ensamblados a los que hace referencia que VS parece no poder resolver:

Microsoft.ReportViewer.Common
Microsoft.ReportViewer.WinForms
Syncfusion.Compression.Base
Syncfusion.Core
Syncfusion.XlsIO.Base

Los ensamblados de Syncfusion son de un paquete de componentes de terceros. Los otros dos están relacionados con el componente Microsoft ReportViewer.

Las referencias se han agregado a través de la ventana Agregar referencia, en la pestaña .NET, por lo que no creo que haya nada sospechoso al respecto. En la ventana de propiedades para la referencia de ensamblado, no hay ningún valor en Cultura, Descripción, Ruta, Versión de tiempo de ejecución o Nombre fuerte. La versión dice 0.0.0.0 y Resolved is False. Supongo que es bastante obvio que VS no puede resolver la referencia. Mi pregunta es por qué ??? Me he rascado la cabeza mucho más de este. Esto solo ocurre en el servidor, la solución se compila perfectamente en mi máquina y en mi máquina de compañeros de trabajo. Las propiedades de referencia del conjunto están bien en nuestras máquinas.

Intenté desinstalar el componente de terceros (en el servidor, por supuesto) y luego volver a instalarlo. No ayudó. Intenté reparar la instalación de VS2008 . No ayudó. Intenté recuperar una versión anterior del control de código fuente (que sé que tiene Buildt en el servidor anteriormente), y recibí los mismos mensajes de error. Revisé los permisos de archivos y todo parece estar en orden. Me estoy quedando sin ideas...

¿Cómo puedo solucionar esto?

Actualización 16.02.2009:
Intenté comparar la salida ildasm del dll en mi pc y en el servidor (vea el comentario que escribí sobre eso), y hay una pequeña diferencia en una línea que para mí parece ser un comentario. Debo admitir que no entiendo por qué hay una diferencia en absoluto, entonces ¿alguien podría explicarme eso?
También intenté ejecutar un análisis de virus en el servidor. No ayudó. Intenté eliminar la referencia y luego leerla navegando a la dll en el disco. No funcionó

Actualización 17.03.2009:
¡Encontré la solución! El culpable fue el módulo TruPrevent de Panda Antivirus . Después de deshabilitar el módulo, ¡todo funciona! =)
Descubrí esto con la ayuda de fuslogvw.exe y el log generado. Busqué en Google el resultado y tropecé con esta entrada de blog. . Espero que esto pueda ayudar a alguien más a hacerlo.

Tuvimos el mismo problema, resulta que la unidad C estaba llena (solo tenía 28 MB).
Liberar espacio resolvió el problema, a pesar de que la construcción ocurre en D.

¿Ves alguna diferencia entre ildasm de este archivo

''C: / Archivos de programa / Syncfusion / Essential Studio / 7.1.0.21 / Assemblies / 3.5 / Syncfusion.XlsIO.Base.dll''

en tu máquina versus en el servidor?

Mi sospecha es que el usuario que está bajo el proceso de compilación no tiene acceso a la carpeta en la que se encuentra su control de terceros. Dado que esto funciona correctamente en sus máquinas, es casi seguro que sea específico del usuario / permiso.

También podría ser que los ensamblados a los que se hace referencia estén en el GAC en la máquina de desarrollo, pero no en la máquina de compilación. Sáquelo del GAC, en su repositorio de origen y haga referencia a él por ruta.

Su dll de terceros puede depender de dlls no administradas. A menudo se debe a que falta una versión específica de VC ++ Runtime Dlls.

Abra el Dll con Dependency Walker http://www.dependencywalker.com/ en su servidor y verifique si faltan referencias.

Casi con certeza, el problema es ambiental, no está relacionado con la fuente.

Algunas ideas ...

(i) Intente desactivar sus herramientas antivirus / antimalware. He visto casos en los que estas herramientas (particularmente Trend Micro Antivirus, por algún motivo) pueden mantener un archivo DLL bloqueado después de (durante?) escanear, interfiriendo con los compiladores.

(ii) Verifique su variable de entorno PATH. Incluso en estos días modernos, la variable PATH se utiliza para resolver algunas cosas: si esto está mal (demasiado largo, la longitud máxima es de 2048 caracteres IIRC), entonces las cosas pueden ser extrañas.

(iii) Ha revisado los permisos de archivo. ¿Ha verificado los permisos en el registro? Por ejemplo, SyncFusion instala su clave de licencia en las colmenas Usuario y Máquina: si el servidor de compilación no puede leer una u otra, podría causar problemas.

¡Buena suerte!

No estoy seguro si esto lo ayudará en su caso, pero sí tuve algo similar antes de que un dll aparentemente no se registrara de alguna manera, y ejecutar regsvr32 en el dll hizo el truco.