¿Por qué estoy recibiendo 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?

Question

Inmediatamente después de actualizar a Visual Studio 2010 y el marco 4.0 nuestra estructura de troncales comenzó a romperse con el No se pudo cargar el archivo o el error de ensamblaje.

se determinó que un proyecto 3.5 no podría hacer referencia a un proyecto de 4.0 otro que tendríamos este error porque, como los estados de error, Este conjunto está construido por un tiempo de ejecución más reciente que el tiempo de ejecución actualmente cargado y no se puede cargar .

Hemos resuelto esto y el maletero ha estado funcionando bien.

Recientemente hice una rama y una etiqueta, sin embargo, y de repente este error ha resurgido cuando intento construir la rama; excepto que el error está relacionado con una de nuestras propias referencias del 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 ensamblado de referencia

"C: \ Windows \ Microsoft.Net \ assembly \ GAC_MSIL \ System.Configuration \ v4.0_4.0.0.0__b03f5f7f11d50a3a \ System.Configuration.dll ".
Captura una BadImageFormatException que dice "No se pudo cargar el archivo o ensamblado
" 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 ensamblado 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é configurar la propiedad de la versión específica en ese sistema. La configuración DLL ref a verdadero.
Veo en sus propiedades que la versión de tiempo de ejecución es v4.0.30319 y la versión es 4.0.0.0.
La ruta a la referencia de DLL es C: \ Archivos de programa (x86) \ Assemblies \ Microsoft \ Framework.NETFramework \ v4.0 \ System.Configuration.dll de referencia que a mí se ve bien.

El marco de destino para el archivo csproj que CrusieControl está utilizando MSBuild para intentar compilar es el marco de segmentación 4.0. De nuevo parece estar bien.

Se basa en el IDE para ambos troncos & rama. Cruise Control contruya en el maletero. La compilación de sucursales falla cuando CrusieControl intenta compilar.

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

Podría ser una discrepancia de MSBuild pero he escaneado los archivos de configuración y los archivos de projecto msbuild que CruiseControl está usando y no hay referencias a MSBuilds anteriores; lo cual tiene sentido ya que todos estos fueron actualizados para que el tronco funcione.

La rama era simplemente una copia del maletero, así que estoy teniendo dificultades para determinar cuál puede ser la diferencia.

Answer 1

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

Answer 2

La diferencia podría ser fácilmente rutas 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 otra que pueda entrar si ccnet.config apunta a un script de construcción que llama a msbuild en lugar de directamente a un archivo .sln o .csproj.

Encienda /v:d for the msbuild en AMBAS y luego compare las resoluciones de referencia (o el orden de compilación, etc.) para ese conjunto u otros involucrados/cerca de él.

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

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

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

en su ccnet.config?

que he visto que informan el ejecutable 2.0 build durante una msbuild4 /tv:3.5:

<Message Text="MSBuildToolsPath:$(MSBuildToolsPath)" /> 
<Message Text="MSBuildToolsVersion:$(MSBuildToolsVersion)" /> 

MSBuildToolsPath:C:\WINNT\Microsoft.NET\Framework\v2.0.50727 
MSBuildToolsVersion:2.0 

de manera que no parece muy útil.

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

Sé que tenía algunas rutas en el script de construcción que fallaron en mi bifurcación porque había una ruta de acceso codificada que no sería válida para la sucursal. Tuve que ajustar el ccnet.config para pasar los argumentos para que esos artículos se reemplazaran para la rama.

Answer 3

Consulte la versión de .net framework compatible con su cliente. Por ejemplo, sharepoint2010 no admitirá dll creado por 4.0 o superior .NET Framework. Solo admitirá 3.5 o menos.

Answer 4

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