instalar - Visual Studio 2010: ensamblados de referencia que apuntan a una versión de mayor marco

visual studio code format code

Question

Visual Studio 2008 sí le permitió hacer referencia a un ensamblado A desde un ensamblaje B cuando A apuntaba a .NET 3.5 y B apuntaba a .NET 2.0.

Visual Studio 2010 ya no permite esto. El problema completo se describe en MSDN :

Puede crear aplicaciones que hagan referencia a proyectos o ensamblados que se dirijan a diferentes versiones de .NET Framework. Por ejemplo, si crea una aplicación que se dirija a .NET Framework 4 Client Profile, ese proyecto puede hacer referencia a un ensamblado que se dirija a .NET Framework versión 2.0. Sin embargo, si crea un proyecto que se dirige a una versión anterior de .NET Framework, no puede establecer una referencia en ese proyecto a un proyecto o ensamblado que se dirija a .NET Framework 4 Client Profile o .NET Framework 4 . Para eliminar el error, asegúrese de que el perfil al que apunta su aplicación es compatible con el perfil al que apuntan los proyectos o ensamblados a los que hace referencia su aplicación.

¿Hay alguna manera en que pueda hacer que VS2010 se comporte como VS2008 en este aspecto (es decir, permitiendo referencias a ensamblados que tengan como objetivo versiones de marco más altas)?

Conozco el razonamiento detrás del comportamiento de VS 2010 y las consideraciones de implementación que debo tener en cuenta, sin necesidad de repetir eso.

El error exacto es:

Advertencia MSB3268: La referencia principal "xxx.dll" no se pudo resolver porque tiene una dependencia indirecta del ensamblado de la infraestructura "System.Core, Version = 3.5.0.0, Culture = neutral, PublicKeyToken = b77a5c561934e089" que no se pudo resolver en el marco actualmente orientado. ".NETFramework, Version = v2.0". Para resolver este problema, elimine la referencia "xxx.dll" o redirija su aplicación a una versión de marco que contenga "System.Core, Version = 3.5.0.0, Culture = neutral, PublicKeyToken = b77a5c561934e089".

Answer 1

La numeración de la versión de .NET Framework tiene que ser un desastre después de 2.0. Un ensamblado no se dirige a una versión de .NET framework, se dirige a una versión CLR. Y la versión de CLR para las versiones de framework 2.0, 3.0 y 3.5 era la misma, 2.0.50727.

Por eso parecía que podía mezclar versiones en VS2008. Pero estaba viendo la [AssemblyVersion] de un ensamblaje, que no tiene nada que ver con la versión de CLR. Desafortunadamente, la versión de CLR no está visible en la ventana de Propiedades, tendrías que ejecutar Ildasm.exe para verla en los metadatos. Pero puede suponer con seguridad que cualquier versión de ensamblaje entre 2.0.0.0 y 3.5.0.0 se dirige a CLR versión 2.0.50727

Eso terminó con .NET 4.0, obtuvo una nueva versión de CLR, 4.0.30319. Lo que la propaganda de MSDN le dice que cuando se dirige a la versión 2.0 de CLR, entonces no puede usar ensamblajes que tengan como objetivo 4.0. La versión 2.0 CLR no sabe cómo leer los metadatos de un ensamblado .NET 4.0, se cambió el formato. La única solución consiste en obligar al EXE a cargar la versión 4.0 del CLR, aunque solicite 2.0.50727. Usted hace eso con un archivo app.exe.config, debería verse así:

<configuration>
<startup>
<supportedRuntime version="v4.0"/>
</startup>
</configuration>

Y un poco de prueba de que todavía funciona correctamente, Microsoft usó v4.0 para reparar varios errores antiguos en 2.0 que no podían repararse fácilmente sin tomar el riesgo de descifrar el código antiguo que dependía del comportamiento del buggy.

Answer 2

Paso 1: descargue el proyecto de referencia dirigido a .NET 2.0

Paso 2: haga clic con el botón derecho en el proyecto descargado y seleccione editar desde el menú contextual

Paso 3: Agregue <SpecificVersion>true</SpecificVersion> a la referencia. A continuación se muestra una muestra de mi solución repro:

<ProjectReference Include="../HighFX/HighFX.csproj">
<Project>{8DD71CAF-BEF7-40ED-9DD0-25033CD8009D}</Project>
<Name>HighFX</Name>
<SpecificVersion>true</SpecificVersion>
</ProjectReference>

Paso 4: recarga el proyecto.

Ahora debería poder compilar dentro de Visual Studio 2010, todavía podría haber una advertencia como la siguiente, pero la construcción puede ser exitosa.

Fuente: http://social.msdn.microsoft.com/Forums/en-US/msbuild/thread/dfadfb34-5328-4c53-8274-931c6ae00836

Answer 3

Por favor, vaya a Visual Studio 2015

1. Primero, proceda haciendo clic derecho en su proyecto
2. Seleccione las propiedades del proyecto
3. Seleccione la pestaña Aplicación (pestaña predeterminada)
4. Cambie el Marco de objetivos al marco deseado para ese proyecto específico. La imagen de este proceso se muestra aquí

Answer 4

Add <SpecificVersion>true</SpecificVersion> to the reference

En una solución grande con muchos proyectos haciendo referencia entre sí, esto podría tener un efecto de cascada, que es un dolor de arreglar manualmente. Para automatizar el proceso, escribí el script de PowerShell a continuación. Ejecútelo en el nivel superior de su solución: el script busca recursivamente los archivos .csproj y actualiza los elementos ProjectReference que coinciden con los GUID parciales (que debe especificar editando la línea relevante del script) .

dir -recurse -filter *.csproj | foreach {
$xml = New-Object XML
$xml.Load($_.FullName)
# we want the ItemGroup that contains the references
$itemgroup = $xml.Project.ItemGroup | where { $_.ProjectReference }
# Project GUIDs to search for... (edit as needed for your projects)
$projrefs = $itemgroup.ProjectReference `
| where { !$_.SpecificVersion `
-and ( $_.Project -like "*CF2185B1*" `
-or $_.Project -like "*CF2185B2*" `
-or $_.Project -like "*CF2185B3*") `
}
if ($projrefs) {
Write-Host $_.FullName
foreach($ref in $projrefs) {
if($ref) {
# <specificversion>true</specificversion>
$el = $xml.CreateElement("SpecificVersion", $xml.Project.xmlns)
$el.InnerText = "true"
$ref.AppendChild($el) | out-null
Write-Host " updated: " $ref.Name
}
}
$xml.Save($_.FullName)
}
}
Write-Host "Press any key to continue ..."
$host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown")