Visual Studio 2010: Reference Assemblies Targeting Higher Framework Version

Question

Visual Studio 2008 did let you reference an assembly A from an Assembly B when A was targeting .NET 3.5 and B was targeting .NET 2.0.

Visual Studio 2010 doesn't allow for this any more. The full issue is described on MSDN:

You can create applications that reference projects or assemblies that target different versions of the .NET Framework. For example, if you create an application that targets the .NET Framework 4 Client Profile, that project can reference an assembly that targets .NET Framework version 2.0. However, if you create a project that targets an earlier version of the .NET Framework, you cannot set a reference in that project to a project or assembly that targets the .NET Framework 4 Client Profile or the .NET Framework 4. To eliminate the error, make sure that the profile targeted by your application is compatible with the profile targeted by the projects or assemblies referenced by your application.

Is there any way I can get VS2010 to behave like VS2008 in this regard (i.e. allowing references to assemblies targeting higher framework versions)?

I know the reasoning behind the VS 2010 behavior and the deployment considerations I need to be aware of, no need to repeat that.

The exact error is:

warning MSB3268: The primary reference "xxx.dll" could not be resolved because it has an indirect dependency on the framework assembly "System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" which could not be resolved in the currently targeted framework. ".NETFramework,Version=v2.0". To resolve this problem, either remove the reference "xxx.dll" or retarget your application to a framework version which contains "System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089".

Solution 1

Step1: Unload the referencing project targeting .NET 2.0

Step2: Right click the unloaded project and select edit from context menu

Step3: Add <SpecificVersion>true</SpecificVersion> to the reference. Below is a sample from my repro solution:

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

Step4: Reload the project.

Now your should be able to build within the Visual Studio 2010, there could still be a warning as below, but the build can be successful.

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

Solution 2

The .NET framework version numbering got to be a mess after 2.0. An assembly does not target a .NET framework version, it targets a CLR version. And the CLR version for framework versions 2.0, 3.0, and 3.5 was the same, 2.0.50727.

Which is why it looked like you could mix versions in VS2008. But you were seeing the [AssemblyVersion] of an assembly, which has nothing to do with the CLR version. Unfortuntely, the CLR version isn't visible in the Properties window, you'd have to run Ildasm.exe to see it in the metadata. But you can safely assume that any assembly version between 2.0.0.0 and 3.5.0.0 targets CLR version 2.0.50727

That ended with .NET 4.0, it got a new CLR version, 4.0.30319. What the MSDN blurb is telling you that when you target CLR version 2.0 then you cannot use assemblies that target 4.0. The version 2.0 CLR doesn't know how to read the metadata of a .NET 4.0 assembly, the format was changed. The only workaround is to force the EXE to load the 4.0 version of the CLR, even though it asks for 2.0.50727. You do that with an app.exe.config file, it should look like this:

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

And a bit of testing that it still works correctly, Microsoft used v4.0 to fix several old bugs in 2.0 that couldn't easily be fixed without taking the risk to break old code that relied on the buggy behavior.

Solution 3

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

In a large solution with many projects referencing each other, this could have a cascading effect, which is a pain to fix manually. To automate the process, I wrote the PowerShell script below. Run it in the top level of your solution--the script searches recursively for .csproj files and updates the ProjectReference elements matching the partial GUIDs (which you must specify by editing relevant line of the 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")

Solution 4

Please go to the Visual Studio 2015

1. First, Proceed with Right-clicking on your project
2. Select the Project Properties
3. Select the Application tab(Default tab)
4. Change the Target Framework to the desired framework for that specific project.Image for this process is shown here

View more solutions

Comments

[aaddesso]

I know that, and this is exactly why I'm wondering it doesn't work anymore. None of my projects is a 4.0 project but there are 2.0 projects referencing 3.5 projects (which should work fine).

[user1703401]

I didn't see you mention any kind of error message in your question. Cannot help you without that message.

[aaddesso]

@Hans: Thanks for investigating, I have included the relevant error message.

[user1703401]

It is a proper warning message. System.Core.dll is not available on .NET 2.0. You'll need to target 3.5. Feature, not a bug.

[aaddesso]

@Hans: Sorry to roll this up again, But exactly this scenario worked in 2008. I know the difference between CLR and Framework versions just as well as you do, but since .net 3.5 and 2.0 target CLR 2 referencing a 3.5 assembly from a 2.0 project was possible in 2008 but is no longer in 2010.

[user1703401]

Well, CLR 2.0 has no trouble loading a .NET 3.5 assembly. This actually working on a machine that only has .NET 2.0 or 3.0 installed would be a bit of a miracle, the assembly won't be there. But CLR 2.0 fundamentally can never load a 4.0 assembly, the metadata format has changed. The same reason CLR 1.x can never load a 2.0 assembly.

[Muhammedh]

Worked like a charm! Thanks :-)!!

[Jay]

Freaking brilliant. that's what I call a helpful answer on SO. Thank you!!

[Rod]

This worked for me too. We have some people using different versions of VS 2015 or VS 2017. Will that entry affect users of VS 15?