Bug 57842 - Unable to reference .NET Standard 2.0 libraries from iOS Library project
Summary: Unable to reference .NET Standard 2.0 libraries from iOS Library project
Alias: None
Product: iOS
Classification: Xamarin
Component: MSBuild ()
Version: XI 10.12 (d15-3)
Hardware: PC Mac OS
: Normal normal
Target Milestone: Future Cycle (TBD)
Assignee: Alexander Köplinger [MSFT]
: 59270 59475 59665 ()
Depends on:
Reported: 2017-06-28 17:46 UTC by Aaron Bockover [MSFT]
Modified: 2017-11-02 23:00 UTC (History)
9 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Aaron Bockover [MSFT] 2017-06-28 17:46:11 UTC
1. create a new iOS library project

2. create a new .NET Standard 2.0 library project

3. attempt to reference the .NET Standard 2.0 library project from the iOS library project

4. attempt to build the iOS library project and notice the failure:

/Library/Frameworks/Mono.framework/Versions/5.2.0/lib/mono/xbuild/Microsoft/NuGet/Microsoft.NuGet.targets(5,5): Error: Your project is not referencing the "Xamarin.iOS,Version=v1.0" framework. Add a reference to "Xamarin.iOS,Version=v1.0" in the "frameworks" section of your project.json, and then re-run NuGet restore. (iOSLibrary)

At this point there are no NuGets to restore, nor is there a project.json to edit. The iOS library's .csproj (old style) still has its target framework set to Xamarin.iOS.

5. add the .NETStandard 2.0 NuGet (preview) to the iOS project and try to rebuild again, and note the same build error.
Comment 1 Aaron Bockover [MSFT] 2017-06-28 17:46:47 UTC
This is with 15.3 preview 4 ("beta channel") on Mac:

Version: (Visual Studio Enterprise)
Hash: 104e7b43
Branch: d15-3
Build date: 2017-06-08 14:59:48-0400
Comment 2 Aaron Bockover [MSFT] 2017-06-28 17:51:05 UTC
More complete repro steps and full git history showing each step: https://github.com/abock/bxc57842-repro-case
Comment 3 Alexander Köplinger [MSFT] 2017-06-29 17:08:54 UTC
I digged into it and this seems to be because the .csproj's are all in the same folder.
Moving them into separate folders like I did in https://github.com/akoeplinger/bxc57842-repro-case/commit/6e8ad2652b60171ba209a79bc3f8035e8b8002f7 makes the project build for me both on command line and in VSMac.

I'll continue looking around but my hunch is that the nuget/netstandard logic doesn't like the packages.config in the folder and bails.

@Aaron: do you have a use case for keeping the csproj's in the same folder as opposed to the more common folder-per-project layout?


Visual Studio Enterprise 2017 for Mac (Preview)
Version 7.1 Preview (7.1 build 1178)
Installation UUID: 1c991547-581e-4f90-ab95-30ac94e4290d
	Mono (2017-06/a6612b4) (64-bit)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 504000081

Version: (Visual Studio Enterprise)
Hash: 104e7b43
Branch: d15-3
Build date: 2017-06-08 14:59:48-0400
Comment 4 Alexander Köplinger [MSFT] 2017-06-29 17:31:37 UTC
Hmm, it seems to be due to the new nuget task that takes care of <PackageReference>.

If I add <ResolveNuGetPackages>false</ResolveNuGetPackages> to the iOSLibrary.csproj then it works even in the same folder.

This might be "by design" from nuget's side.
Comment 5 Aaron Bockover [MSFT] 2017-06-29 18:14:11 UTC
The scenario I laid out in the repro steps is how VSM structures projects within the solutions out of the box, so this is going to be common, regardless of our "use case".

But to speak to the use case in particular, yes, we would want this structured in that manner (SxS .csproj in the same directory structure). Basically - we need to structure three separate projects around one directory structure of code:

1. a shared project
2. a PCL project that consumes a subset of the directory structure
3. and now a .NET Standard project that consumes essentially pieces (1) and (2)

Ultimately we will migrate all of this into a single and only .NET Standard project, but we have to migrate in pieces. The existing structure in place was necessary in a PCL + Bait-and-switch world.

But again, you run into this issue out-of-the-box in VSM just by adding two projects to a solution.
Comment 6 Jeffrey Stedfast 2017-07-11 13:56:54 UTC
FWIW, I hit this very same sort of problem with MimeKit/MailKit on Windows and had to rename my packages.config file to be csproj-file-specific by chopping off the ".csproj" file extension and then prepending "packages." to the file name and appending ".config" as the new extension. You'll need one of these files for each *.csproj file.

In other words, if you have:


You'll need:


That's the only way I was able to get this to work.

Matt Ward is the one who made this suggestion to me.
Comment 7 Jeffrey Stedfast 2017-07-31 19:09:27 UTC
*** Bug 58504 has been marked as a duplicate of this bug. ***
Comment 8 Jeffrey Stedfast 2017-09-18 19:05:24 UTC
*** Bug 59270 has been marked as a duplicate of this bug. ***
Comment 9 Jeffrey Stedfast 2017-09-19 15:15:40 UTC
*** Bug 59475 has been marked as a duplicate of this bug. ***
Comment 10 Jeffrey Stedfast 2017-09-26 16:36:49 UTC
*** Bug 59665 has been marked as a duplicate of this bug. ***
Comment 11 Jeffrey Stedfast 2017-09-26 17:47:53 UTC
Does this just work now? Is there really anything that needs to be done in the iOS-specific msbuild tasks?

Seems to be working locally for me...
Comment 12 Vincent Dondain [MSFT] 2017-11-02 23:00:47 UTC
Does not happen to me with the following version information: https://gist.github.com/VincentDondain/56a164233f5a4f3e90dbd7f2deaa95e2

Test case: https://www.dropbox.com/s/l8krw75buiber9h/Bug57842.zip?dl=0

Feel free to re-open if you're still experiencing the issue.