assemblies - ¿Por qué recibo No se pudo cargar el archivo o el error de ensamblaje en una DLL de configuración del sistema cuando se usa Framework 4.0?

.net-4.0 cruisecontrol.net

Question

Inmediatamente después de actualizar a Visual Studio 2010 y al marco 4.0, nuestra construcción de troncal comenzó a fallar con el error No se pudo cargar el archivo o el ensamblaje.

Determinamos que un proyecto 3.5 no podría hacer referencia a un proyecto 4.0; de lo contrario, obtendríamos este error porque, como indica el error, este ensamblado se construye con un tiempo de ejecución más nuevo que el tiempo de ejecución cargado actualmente y no se puede cargar .

Hemos resuelto esto y el maletero ha estado construyendo bien.

Sin embargo, recientemente hice una rama y una etiqueta, y de repente este error ha vuelto a aparecer cuando intento construir la rama; excepto que el error está relacionado con una de las referencias de nuestro propio proyecto .net 4.0 a System.Configuration DLL.

Towps.Namespace.MyService.csproj en Core.Dev / Towps / Projetcs / Application / MyService:
RG0000: No se pudo cargar el ensamblaje referenciado

"C: / Windows / Microsoft.Net / assembly / GAC_MSIL / System.Configuration / v4.0_4.0.0.0__b03f5f7f11d50a3a / System.Configuration.dll".
Capturó una excepción BadImageFormatException que decía "No se pudo cargar el archivo o el ensamblaje
''C: / Windows / Microsoft.Net / assembly / GAC_MSIL / System.Configuration / v4.0_4.0.0.0__b03f5f7f11d50a3a / System.Configuration.dll'' o una de sus dependencias.
Este ensamblaje está construido por un tiempo de ejecución más nuevo que el tiempo de ejecución cargado actualmente y no se puede cargar. ". En ResGen (0, 0)

Intenté establecer la propiedad de versión específica en ese sistema. Configuración DLL ref. A verdadero.
Puedo ver en sus propiedades que la versión de tiempo de ejecución es v4.0.30319 y la versión 4.0.0.0.
La ruta a la referencia de la DLL es C: / Archivos de programa (x86) / Referencias de referencia / Microsoft / Framework.NETFramework / v4.0 / System.Configuration.dll, que para mí se ve bien.

El marco de destino para el archivo csproj que CrusieControl está utilizando MSBuild para tratar de construir es el marco de destino 4.0. De nuevo parece estar bien.

Se basa en el IDE para el tronco y la rama. Control de crucero construirlo en el maletero. La construcción de la rama falla cuando CrusieControl intenta construir.

¿Alguna idea de lo que podría estar pasando?

Podría ser una falta de coincidencia de MSBuild, pero he escaneado los archivos de configuración y los archivos de proyecto msbuild que utiliza CruiseControl y no hay referencias a MSBuilds más antiguos; lo que tiene sentido ya que todos los que se actualizaron para que el tronco funcione.

La rama era simplemente una copia del tronco, ¡así que estoy teniendo dificultades para determinar cuál podría ser la diferencia!

Answer 1

Por favor verifique la versión de .net framework soportada por su cliente. Por ejemplo, sharepoint2010 no admitirá dll creado por 4.0 o un marco .net superior. Sólo soportará 3.5 o menos.

Answer 2

Resulta que después de bifurcar, todos los archivos .proj en el directorio de compilación de mi sucursal que usa cc.net volvieron a usar ToolVerison = "3.5". Pensé que había cometido todos los cambios de configuración y proyecto de ToolsVersion = "4.0" en el tronco desde el que hice la rama; evidentemente no.

Answer 3

Un poco tarde, lo sé, pero si alguien más tiene este problema, intente agregar RuntimeVersion en su archivo .dna si aún no existe.

<DnaLibrary Name="PROJECTNAME" RuntimeVersion="v4.0">

Answer 4

La diferencia podría ser fácilmente pistas de pistas que ya no se alinean en la nueva rama. Sin embargo, no hay un registro para continuar en su descripción. ¿Cuáles son las opciones de línea de comando que está pasando? En ccnet.config y también cualquier otro que pueda ingresar si ccnet.config apunta a un script de construcción que llama a msbuild en lugar de directamente a un .sln o .csproj .

Active /v:d for the msbuild en BOTH y luego compare las resoluciones de referencia (u orden de compilación, etc.) para ese ensamblaje u otros involucrados / cercanos al mismo.

También está proporcionando la ruta de acceso a msbuild en ambos?

msbuild4="C:/WINNT/Microsoft.NET/Framework/v4.0.30319/MSBuild.exe"

<msbuild>
<executable>$(msbuild4)</executable>

en su ccnet.config ?

Lo he visto reportando el ejecutable de compilación 2.0 durante un msbuild4 /tv:3.5 :

<Message Text="MSBuildToolsPath:$(MSBuildToolsPath)" />
<Message Text="MSBuildToolsVersion:$(MSBuildToolsVersion)" />
MSBuildToolsPath:C:/WINNT/Microsoft.NET/Framework/v2.0.50727
MSBuildToolsVersion:2.0

Así que eso no me pareció muy útil.

Me gustaría ver los bloques de configuración para la rama y el tronco.

Sé que había algunas rutas en el código de compilación que fallaron en mi rama porque había una ruta codificada que no sería válida para la rama. Tuve que ajustar el ccnet.config para pasar los argumentos para que esos elementos se anulen para la rama.