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

onovotny opened this Issue Dec 19, 2016 · 2 comments


None yet

3 participants


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:

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.

@onovotny onovotny added a commit to onovotny/microsoft-authentication-library-for-dotnet that referenced this issue Dec 19, 2016
@onovotny onovotny build net45 first to workaround dotnet/sdk#535 so unit tests run for now f8880e6
@onovotny onovotny referenced this issue in AzureAD/microsoft-authentication-library-for-dotnet Dec 19, 2016

Simplify project structure & move to .NET Standard #135

3 of 5 tasks complete
@nguerrera nguerrera was assigned by srivatsn Dec 21, 2016
@srivatsn srivatsn added the Bug label Dec 21, 2016
@srivatsn srivatsn added this to the 1.0 RC3 milestone Dec 21, 2016

@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?


This issue was moved to dotnet/roslyn-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