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

P2P refs choose first tfm in multi-targting reference, not closest one #535

Closed
onovotny opened this Issue Dec 19, 2016 · 2 comments

Comments

Projects
None yet
3 participants
@onovotny
Member

onovotny commented Dec 19, 2016

In my solution, I have a multi-targeting project creating the following outputs: netstandard1.2;netstandard1.3;net45;win81;wpa81;MonoAndroid70;Xamarin.iOS10

When I do a P2P reference from an iOS app, a NET 4.5 unit test project, etc, they all pick netstandard1.2 as shown on the properties path of the reference:
ref

You can repro this by loading the following onovotny/microsoft-authentication-library-for-dotnet@d41e237.

Build src\Microsoft.Identity.Client and then look at the properties of the test project below (and of the other sample projects.

@nguerrera

This comment has been minimized.

Show comment
Hide comment
@nguerrera

nguerrera Jan 13, 2017

Member

@onovotny What I am seeing is that build actually selects the correct TFM, (change output level to detailed and see /reference arg to compiler) but the property pane does incorrectly show the path of the first target framework.

I presume that you have worse symptoms than a bad path in the properties pane by the description of "so unit tests run for now" in your workaround commit. However, when I make a unit test from the net45 app that asserts that a method which returns the TFM does what I expect, it works fine. Do you have a (hopefully simple) repro for this causing unit tests to fail?

One thing I'm now noticing on top of the property pane being incorrect is that IntelliSense is showing me completions based on the surface are of the first TFM and not the one that a real build would use. I presume that has the same root cause as the bad property pane value.

Based on these obeservations, I think this is better tracked on https://github.com/dotnet/roslyn-project-system. @mavasani, @davkean What do you think?

Member

nguerrera commented Jan 13, 2017

@onovotny What I am seeing is that build actually selects the correct TFM, (change output level to detailed and see /reference arg to compiler) but the property pane does incorrectly show the path of the first target framework.

I presume that you have worse symptoms than a bad path in the properties pane by the description of "so unit tests run for now" in your workaround commit. However, when I make a unit test from the net45 app that asserts that a method which returns the TFM does what I expect, it works fine. Do you have a (hopefully simple) repro for this causing unit tests to fail?

One thing I'm now noticing on top of the property pane being incorrect is that IntelliSense is showing me completions based on the surface are of the first TFM and not the one that a real build would use. I presume that has the same root cause as the bad property pane value.

Based on these obeservations, I think this is better tracked on https://github.com/dotnet/roslyn-project-system. @mavasani, @davkean What do you think?

@srivatsn

This comment has been minimized.

Show comment
Hide comment
@srivatsn

srivatsn Jan 13, 2017

Collaborator

This issue was moved to dotnet/project-system#1162

Collaborator

srivatsn commented Jan 13, 2017

This issue was moved to dotnet/project-system#1162

@srivatsn srivatsn closed this Jan 13, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment