Roslyn: "Primary reference cannot be resolved" when referencing netstandard PCL from profle-based PCL

[rchande]

New PCL, Target .NET Standard 1.0
New PCL, Windows 8.1/.NET 4.5

Add a P2P ref to the first project from the second and build.

C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(1820,5): warning MSB3274: The primary reference "c:\users\rchande\documents\visual studio 2015\Projects\ClassLibrary13\ClassLibrary1\bin\Debug\ClassLibrary1.dll" could not be resolved because it was built against the ".NETPortable,Version=v5.0" framework. This is a higher version than the currently targeted framework ".NETPortable,Version=v4.5,Profile=Profile7"

[DustinCampbell]

Moving this forward out of 1.3. @rchande: is this still an issue?

[clairernovotny]

This is still an issue. The issue seems to stem from the way libraries are compiled. It’s a CS Proj PCL that targets .NET Standard 1.0. The issue is that libraries compiled this way have their assembly TargetFrameworkAttribute set to “.NETPortable,Version=v5.0”. This differs from a library created with xproj/project.json where the value is “.NETStandard,Version=v1.0”.

Apparently this is causing a compiler error. This attribute is generated as part of the build.

@dsplaisted had a temporary workaround here: https://github.com/dsplaisted/NetStandardTFMFix/commit/43ad5119a2632765979e12cef8904e6d2408923a
but it requires library authors using csproj to add hacks into their projects.

[ufcpp]

I saw one who encountered the same problem. He created minimal repro projects:
https://github.com/runceel/netstandardandpcl

[rchande]

@rchande Make sure the fix for this was ported to Dev 15

[tmori3y2]

I can regenerate this issue by using VS2015 version 14.0.25424.00 (Update3 released on 07/20/2016).
But I cannot regenerate this issue by using VS2015 version 14.0.25431.01 (Update3 released on 09/14/2016).

By the way, I installed the .net standard based nuget package builded by VS2015 into profie-based PCL when using VS2013.
The same issue was occurred.
Is the nuget package targeted only .net standard 1.1 not supported by VS2013 ?

[Pilchie]

@tmori3y2 @rchande fixed this in the portable class library code in the Update 3 patch between those builds, so this is expected.

VS2013's PCL code has no knowledge of .NET Standard at all, but this should only be an issue with P2P references, not references to packages. If you're having issues with package references, https://github.com/nuget/home is probably the right place for them.

[rchande]

Fixed in Micro Update, port to VS Next is in progress--closing.

[cubed-it]

Installing 17RC brought me back this error to my VS2015 installation ...

[Pilchie]

@rchande can you double check that this change made it into the VS 2017 source tree?

[musterid]

@cubed-it did you manage to find a work around? I did try the vs 2017 and after that my vs 2015 project has been broken even if I have uninstalled vs 2017.

[IlSocio]

Same for me :(

[cubed-it]

@musterid no, but i did not really looked for a solution. applying the patch again does not help, repair does not work. i remove my studio and also wiped everything with https://github.com/Microsoft/VisualStudioUninstaller it took 1-2 hrs of my worktime, and my boss was not happy, but after all it is nothing new that you waste a lot of paid time with bugs and perfromance in visual studio ;-)

[musterid]

@cubed-it I did the VisualStudioUninstaller and then reinstall VS 2015 and restarting and adding the vs14-kb3165756 and then it worked.

Thanks for your help

[Pilchie]

@rchande Can you verify that this is fixed in the VS2017 tree and close?

[cubed-it]

Now we have also the issue with the VS Build Tools 2017 RC from 12 December...

[rchande]

@cubed-it Can you tell me what version of VS 2017 and (if you have it) VS 2015 you have installed?

[jasonmalinowski]

@rchande Any idea why this is still tagged with an approved tag?

[cubed-it]

It does not work with either MSBuild Tools or/and VS2017

[rchande]

@cubed-it Have you ever had VS 2015 installed on that machine?

[cubed-it]

no, it is a complete new build server

[lakario]

I'm getting this issue on two separate machines from another .NET Standard project after installing RC17. Based on what I'm reading, I should be able to fix the issue by nuking VS15 and reinstalling it fresh, but that's a horribly time consuming exercise. Should we not expect a more legitimate roll-forward fix?

[rchande]

@lakario What build do you have installed?
This fix is in current RC builds and will be in the next release.

[rchande]

Also @lakario did you have VS 2015 installed on the same machine?

[lakario]

@rchande I updated to the latest version of RC17 yesterday, but the issue remains. I did indeed have VS15 installed on both test machines.

[lakario]

@rchande This is still happening to me. Do I have no other recourse than to remove RC17, remove and scorch 15, and reinstall from scratch?

[ferrydeboer]

Same here after installing VS2017 RC2 next to VS2015. Good learning moment to really not install RC's on a production machine. The RC has only caused me pain since it also is incompatible with VS2015 Xamarin installation and broke that part.

[guperrot]

Why is this closed? The issue still exists today with all tools up-to-date in stable. Libraries built with .NET standard still advertise they were built with ".NETPortable,Version=v5.0". And apparently we have to use a suspicious work around mentioned in this blog.

Can anyone comment on this?