Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.dll in Microsoft.NET.Build.Extensions\net461 targets .NET Framework 4.6.1 #26456

Open
nguerrera opened this Issue Jan 19, 2018 · 13 comments

Comments

Projects
None yet
7 participants
@nguerrera
Copy link
Member

nguerrera commented Jan 19, 2018

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:
image

Copied from original issue: dotnet/sdk#1611

@nguerrera

This comment has been minimized.

Copy link
Member Author

nguerrera commented Jan 19, 2018

From @livarcocc on January 19, 2018 6:49

This may also be a dup of dotnet/sdk#1324.

cc @dsplaisted

@nguerrera

This comment has been minimized.

Copy link
Member Author

nguerrera commented Jan 19, 2018

This is not a dupe of that.

@ericstj @joperezr Where should I move this bug?

@nguerrera

This comment has been minimized.

Copy link
Member Author

nguerrera commented Jan 19, 2018

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

This comment has been minimized.

Copy link
Member

ericstj commented Jan 19, 2018

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 comment has been minimized.

Copy link
Member Author

nguerrera commented Jan 19, 2018

This is dotPeek, not VS.

@ericstj

This comment has been minimized.

Copy link
Member

ericstj commented Jan 19, 2018

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

@jairbubbles

This comment has been minimized.

Copy link

jairbubbles commented Jan 19, 2018

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

image

Better but not good! 😄

(dotPeek version is 2017.3.1)

@jairbubbles

This comment has been minimized.

Copy link

jairbubbles commented Jan 19, 2018

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

@ericstj

This comment has been minimized.

Copy link
Member

ericstj commented Jan 19, 2018

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

Yep: #26456 (comment). 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

This comment has been minimized.

Copy link

jairbubbles commented Jan 19, 2018

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

This comment has been minimized.

Copy link

maartenba commented Jan 22, 2018

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

This comment has been minimized.

Copy link
Member

ericstj commented Jan 22, 2018

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

Got it. Thanks for checking @maartenba

@akoeplinger

This comment has been minimized.

Copy link
Member

akoeplinger commented Jan 23, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.