Visual Studio 2010: Référence Assemblées Ciblage Plus Élevé Framework Version

Question

Visual Studio 2008 vous permettent de faire référence à un assembly A à partir d'un Assemblage B lorsqu'Une cible .NET 3.5 et B est le ciblage .NET 2.0.

Visual Studio 2010 ne permettent pas cela, pas plus. Le coeur du problème est décrit sur MSDN:

Vous pouvez créer des applications projets de référence ou des assemblys de cibler les différentes versions de la .NET Cadre. Par exemple, si vous créez une application qui cible les .NET Framework 4 Client Profile, qui projet peut faire référence à un assembly qui les cibles .NET Framework version 2.0. Toutefois, si vous créez un projet qui les objectifs d'une version antérieure de l' .NET Cadre, vous ne pouvez pas définir un de référence dans ce projet à un projet ou de l'assemblée qui cible les .NET Framework 4 Client Profile ou .NET Cadre 4. Pour éliminer l'erreur, assurez-vous que le profil ciblé par votre application est compatible avec le profil ciblées par les projets ou assemblys référencés par votre application.

Est-il possible que je peux obtenir VS2010 pour se comporter comme des VS2008 à cet égard (c'est à dire permettant des références à des assemblées de ciblage supérieurs versions)?

Je sais que le raisonnement derrière le VS 2010 le comportement et les considérations relatives au déploiement j'ai besoin d'être au courant, pas besoin de le répéter.

L'erreur exacte est:

avertissement MSB3268: La base de référence "xxx.dll" n'a pas pu être résolu, car il a une dépendance indirecte sur l' cadre de l'assemblée "du Système.De base, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" qui n'a pas pu être résolu à l'heure actuelle ciblées cadre. ".NETFramework,Version=v2.0". Pour résoudre ce problème, supprimez la référence "xxx.dll" ou réorienter votre application à un framework version qui contient "Le système de.De Base, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089".

Answer 1

Etape 1: Enlevez le référencement projet de ciblage .NET 2.0

Etape 2: cliquez-Droit sur le projet déchargé et sélectionnez modifier à partir du menu contextuel

Etape 3: Ajouter <SpecificVersion>true</SpecificVersion> à la référence. Ci-dessous est un échantillon de ma repro solution:

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

Etape 4: Recharger le projet.

Maintenant, vous devriez être en mesure de construire au sein de Visual Studio 2010, il pourrait encore être un avertissement comme ci-dessous, mais la construction peut être couronnée de succès.

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

Answer 2

L' .NET framework version de numérotation obtenu d'être un gâchis après la 2.0. Une assemblée n'est pas une cible .NET framework version, il vise une version CLR. Et la version CLR pour cadre les versions 2.0, 3.0 et 3.5 est la même, 2.0.50727.

C'est pourquoi il a regardé comme si on pouvait mélanger les versions dans VS2008. Mais vous avez été voir le [AssemblyVersion] d'une assemblée, qui n'a rien à voir avec la version CLR. Unfortuntely, le CLR version n'est pas visible dans la fenêtre Propriétés, vous devez exécuter Ildasm.exe pour le voir dans les métadonnées. Mais vous pouvez supposer que tout l'assemblage entre la version 2.0.0.0 et 3.5.0.0 cibles version CLR 2.0.50727

Qui a pris fin avec .NET 4.0, il a obtenu une nouvelle version CLR, 4.0.30319. Ce MSDN blurb est vous dire que lorsque vous ciblez CLR version 2.0 alors vous ne pouvez pas utiliser les assemblys qui cible 4.0. La version 2.0 CLR ne savez pas comment lire les métadonnées d'un .NET 4.0 assemblée, le format a été changé. La seule solution est de forcer l'EXE pour charger la version 4.0 du CLR, même si elle demande 2.0.50727. Vous n'avez qu'avec une application.exe.fichier de config, il devrait ressembler à ceci:

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

Et un peu de tests qu'il fonctionne toujours correctement, Microsoft a utilisé v4.0 pour corriger plusieurs bugs dans la version 2.0 qui ne pouvait pas facilement être fixé sans prendre le risque de casser les vieux code qui s'appuient sur le comportement incorrect.

Answer 3

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

Dans une grande solution avec de nombreux projets de référencement les uns des autres, ce qui pourrait avoir un effet en cascade, ce qui est une douleur à résoudre manuellement. Pour automatiser le processus, j'ai écrit le script PowerShell ci-dessous. Exécuter dans le haut niveau de votre solution--le script recherche de manière récursive pour .csproj fichiers et les mises à jour de l' ProjectReference d'éléments correspondant à la partielle Guid (qui vous devez spécifier par l'édition de ligne du 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")