Runtime: .dll in Microsoft.NET.Build.Extensions\net461 targets .NET Framework 4.6.1

[nguerrera]

_From @jairbubbles on September 27, 2017 10:4_

I just noticed that most .dll in C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\ directory target .NET Framework 4.7 which does not seem right.

Here is a dotPeek screenshot:

_Copied from original issue: dotnet/sdk#1611_

[nguerrera]

_From @livarcocc on January 19, 2018 6:49_

This may also be a dup of https://github.com/dotnet/sdk/issues/1324.

cc @dsplaisted

[nguerrera]

This is not a dupe of that.

@ericstj @joperezr Where should I move this bug?

[nguerrera]

_From @joperezr on January 19, 2018 18:47_

These files are built on corefx release/2.0 branch, so I would move it there. This is weird since when we build them we use the 4.6.1 TP but we should move the issue there and investigate.

[ericstj]

I think this might be a VS issue. Those assemblies lack a TargetFrameworkAttribute so VS is likely just reporting them with some default. @nguerrera any chance you know how that string is populated?

[nguerrera]

This is dotPeek, not VS.

[ericstj]

@citizenmatt can you or someone else at JetBrains let us know how you identify the target framework of assemblies in dotPeek?

[jairbubbles]

This is quite and old issue so I looked again on my home pc (Visual Studio Comunity 15.5.3) and I get:

Better but not good! 😄

(dotPeek version is 2017.3.1)

[jairbubbles]

By using Mono.Cecil I can confirm that the assembly does not ~seem to~ have a TargetFrameworkAttribute attribute.

[ericstj]

By using Mono.Cecil I can confirm that the assembly does not seem to have a TargetFrameworkAttribute attribute.

Yep: https://github.com/dotnet/corefx/issues/26456#issuecomment-359058292. I opened an issue to add that. I still find it odd that multiple assemblies that lack the attribute are reported as different frameworks, which is why I'm curious to understand how dotPeek is identifying them.

[jairbubbles]

That's indeed weird because in most cases it seems to fallback to .NET Framework 4.0.

Maybe it's analyzing APIs used in the assembly and computes which .NET Framework would be compatible. If so it seems fairly complex and I wouldn't be surprised that it's not accurate.

[maartenba]

Just checked internally at JetBrains: Specified assemblies are not from folder C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\* and do not have TargetFrameworkAttribute attribute, so we can not correctly determine framework version. In this case we show the latest installed 4.x framework version

[ericstj]

In this case we show the latest installed 4.x framework version

Got it. Thanks for checking @maartenba

[akoeplinger]

@maartenba It think it would be less confusing to show unknown instead of falling back to the installed .NET 😄