Visual Studio 2010: Reference Assemblies Targeting Higher Framework Version

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

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.

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

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