2010-07-21 20 views
35

Visual Studio 2008 sí le permitió hacer referencia a un ensamblaje A desde un ensamblaje B cuando A estaba apuntando .NET 3.5 y B apuntaba a .NET 2.0.Visual Studio 2010: ensamblados de referencia que apuntan a una versión superior de Framework

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

Se pueden crear aplicaciones que proyectos de referencia o conjuntos diana diferentes versiones de la .NET Framework. Por ejemplo, si crea una aplicación dirigida a .NET Framework 4 Client Profile, ese proyecto puede hacer referencia a un ensamblado que tiene como objetivo .NET Framework versión 2.0. Sin embargo, si crea un proyecto que objetivos de una versión anterior de .NET Framework , no se puede establecer una referencia en ese proyecto para un proyecto o montaje destinado a .NET Framework 4 perfil de cliente o el. NET Framework 4. Para eliminar el error, asegúrese de que el perfil al que se dirige su aplicación es compatible con el perfil al que se dirigen los proyectos o los ensamblados a los que hace referencia su aplicación .

¿Hay alguna manera en la que pueda hacer que VS2010 se comporte como VS2008 en este aspecto (es decir, permitiendo referencias a ensamblados dirigidos a versiones de marco superior)?

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

El error exacto es:

advertencia MSB3268: La referencia principal "xxx.dll" no se pudo resolver porque tiene una dependencia indirecta en el conjunto marco "System.Core, Versión = 3.5.0.0, Culture = neutral, PublicKeyToken = b77a5c561934e089 "que no se pudo resolver en el marco de destino actualmente . ".NETFramework, Version = v2.0". Para resolver este problema, quite la referencia "xxx.dll" o reorientar su aplicación a una versión marco que contiene "System.Core, Version = 3.5.0.0, Culture = neutral , PublicKeyToken = b77a5c561934e089 ".

+2

No entiendo por qué querrías hacer eso. ¿No requerirá toda la aplicación la versión superior del marco para comenzar? En ese caso, ¿no tiene sentido enfocarse en la versión más alta? – cHao

+2

Es difícil de explicar, pero hay un requisito razonable detrás de eso. –

+3

Requisito razonable: ensamblado de lógica de negocios ("BL") compartido por un sitio 2.0 ASP.NET y una aplicación 3.5 WinForms. El sitio web utiliza Enterprise Library 3.1 anterior y la aplicación WinForms usa EntLib 5.0 más reciente.Al construir para WinForms, BL necesita cambiar las referencias al EntLib más nuevo, que son 3.5, pero BL necesita seguir siendo un proyecto 2.0 para seguir trabajando con el sitio web 2.0 existente. VS2008 permitió que esto sucediera cambiando las configuraciones, pero VS2010 arroja el error anterior porque EntLib 5.0 espera 3.5 referencias (específicamente, System.Core). –

Respuesta

44

Paso 1: Descargue el proyecto de referencia de orientación .NET 2.0

Paso 2: Haga clic derecho en el proyecto descargado y seleccione Editar en el menú contextual

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

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

Paso 4: vuelva a cargar el proyecto.

Ahora debería ser capaz de compilar dentro de Visual Studio 2010, aún 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

+0

¡Funcionó como un encanto! Gracias :-)!! – Muhammedh

+0

Freaking brilliant. eso es lo que llamo una respuesta útil en SO. ¡¡Gracias!! – Jawad

+0

Esto funcionó para mí también. Tenemos algunas personas que usan versiones diferentes de VS 2015 o VS 2017. ¿Afectará esa entrada a los usuarios de VS 15? – Rod

20

La numeración de la versión de .NET framework tiene que ser un desastre después de la 2.0. Un conjunto hace no se dirige a una versión .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 es que parecía como podrí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 apunta a CLR versión 2.0.50727

que 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 alternativa es force EXE para cargar la versión 4.0 del CLR, aunque solicite 2.0.50727. Usted lo hace con un archivo app.exe.config, debería tener este aspecto:

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

y un poco de las pruebas que todavía funciona correctamente, Microsoft utiliza v4.0 para corregir varios errores de edad en 2.0 que no podía No se puede arreglar fácilmente sin tomar el riesgo de romper el código anterior que se basaba en el comportamiento de errores.

+1

Lo sé, y esta es exactamente la razón por la que me pregunto si ya no funciona. Ninguno de mis proyectos es un proyecto 4.0, pero hay proyectos 2.0 que hacen referencia a 3.5 proyectos (que deberían funcionar bien). –

+0

No vi que mencionaras ningún tipo de mensaje de error en tu pregunta. No puedo ayudarte sin ese mensaje. –

+0

@Hans: Gracias por investigar, he incluido el mensaje de error correspondiente. –

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

En una solución grande con muchos proyectos que hacen referencia a unos de otros, esto podría tener un efecto en cascada, que es un dolor para fijar 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") 
1

Por favor, vaya a la Visual Studio 2015

  1. En primer lugar, proceder con hacer clic derecho en su proyecto
  2. Seleccionar las propiedades del proyecto
  3. Seleccione la ficha Aplicación (pestaña por defecto)
  4. Cambie el marco de trabajo de destino al marco deseado para ese proyecto específico . Image for this process is shown here
Cuestiones relacionadas