Why VS2012 project with referenced assembly can't target 4.0 automatically - reference

Question

In a Visual Studio 2012 C# console application, I downgrade ".NET Framework Target" from 4.5 to 4.0. Win 7 Pro with both Frameworks installed.
I then reference an assembly, which, through warnings complains the following:
The primary reference "System.Threading.Tasks.Dataflow, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" could not be resolved because it has an indirect dependency on the framework assembly "System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" which could not be resolved in the currently targeted framework. ".NETFramework,Version=v4.0". To resolve this problem, either remove the reference "System.Threading.Tasks.Dataflow, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" or retarget your application to a framework version which contains "System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
If I try to compile at this point, I error, becuase types and namespaces from referenced assembly aren't available, as if the assembly was not referenced at all.
The "Add Reference" dialog doesn't have any System.Runtime choice, but if I manually brose to
C:\Windows\Microsoft.NET\Framework\v4.0.30319\
and reference the System.Runtime assembly found there, warnings go away and I am able to compile.
Questions:
Is such forcing of the System.Runtime version a potential issue down the road (deployment).
If VS Project properties are seto to target Framework 4.0 (doesn't that relate to targeting the 4.0 SystemRuntime/CLR), why isn't the refferenced DLL picking that up and why manually adding the reference to my project fixes that issue?

Answer 1

Even though the library System.Runtime is inside the C:\Windows\Microsoft.NET\Framework\v4.0.30319\ directory, it is not part of the .NET 4.0 framework. .NET 4.5 is an in-place update of 4.0 and is installed in the same folder with the same version number.
Here is a screenshot that proofs that the library does not exist on a play .NET 4.0 installation:
You can also validate this by browsing to the C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework directory where you find the original assemblies for all installed framework versions. You will find the System.Runtime.dll as part of the .NETCore\v4.5 and .NETPortable\v4.5 subdirectories.
The reason that you can add the library to your project is that the runtime did not change between 4.0 and 4.5, so Visual Studio doesn't know or even care that the library you added manually is installed by 4.5. In this case the targetting in Visual Studio is only a filter that avoids that you accidentally add a 4.5 assembly to a project that targets 4.0.
Additional information:
Rick Strahl has a very good blog post on the topic with a more detailed analysis:
http://www.west-wind.com/weblog/posts/2012/Mar/13/NET-45-is-an-inplace-replacement-for-NET-40

Answer 2

Is such forcing of the System.Runtime version a potential issue
Yes, this just won't work. It works on your machine because you have 4.5 installed. Your program will crash and burn on a client machine that only has 4.0. Never add a reference from the Framework directory. It is rather sad that they are still around, they get too many programmers in trouble, but backwards compat is sacred.
The build system can only tell you that you have a problem when you use the reference assemblies. The ones shown in the Add Reference dialog, they are stored in c:\program files\reference assemblies and are not the same as the runtime assemblies. You know that works, you did get the warning. Which, in a somewhat clumsy way, told you that you program won't work on a machine that has 4.0. Don't ignore that warning, you really do have to target 4.5 to use that assembly. Hard requirement you cannot avoid.
why isn't the refferenced DLL picking that up
Because it refuses to build a program that cannot run. Feature, not a bug.