VS for Mac unable to add .NET Standard NuGet

Question

I have encountered a weird behavior with VS for Mac. This is how I repro it:

Built a .NET Standard 2.0 NuGet package using VS2017. Package is called "MobileApps.Auth 1.0.0"
Pushed the NuGet to our company NuGet server
Switched over to the Mac and launched VS
On the Mac; Built a Xamarin Forms app (shared project is also .NET Standard 2.0)
Added reference to the .NET Standard 2.0 NuGet

ERROR:

Package MobileApps.Auth 1.0.0 is not compatible with netstandard2.0 (.NETStandard,Version=v2.0). Package MobileApps.Auth 1.0.0 supports:
  - monoandroid81 (MonoAndroid,Version=v8.1)
  - xamarinios10 (Xamarin.iOS,Version=v1.0)

I have zero clues as to why the NuGet would support monodroid81 and xamarinios10. It's a .NET Standard 2.0 library that reference Xamarin.Forms.

If I instead remain on the PC and run steps 4 and 5 in Visual Studio 2017 all is peachy.

This smells like a bug in VS for Mac. Has anyone else seen this?

Overall, having spent a few days building NuGet packages, based on .NET Standard 2.0, both on the Mac and PC I get the overall feeling this doesn't really work on the Mac. The reason I built the NuGet on VS2017 is because NuGet packs built on VS for Mac includes all kinds of facades that causes msbuild to fail due to conflicts (same identifiers found in multiple referenced assemblies).

[EDIT 1]

This is the NuGet layout when package built on VS4M:

_rels (empty folder)
[Content_Types].xml
lib
   netstandard2.0
      MobileApps.Auth.dll (my lib)
      (+ 113 other dlls)
MobileApps.Auth.nuspec
package
   services
      metadata
         core-properties
            5bd1f861cd8a425f854c073a4a5f3e0e.psmdcp

And this is the NuGet layout when built on VS2017:

_rels
   .rels
[Content_Types].xml
lib
   netstandard2.0
      MobileApps.Auth.dll (my lib)
MobileApps.Auth.nuspec
package
   services
      metadata
         core-properties
            5bd1f861cd8a425f854c073a4a5f3e0e.psmdcp

The difference is that VS4M includes 113 extra dlls in the netstandard2.0 folder while VS2017 doesn't. How can I control that?

[EDIT 2]

This is the .nuspec from within the .nupkg, built with VS4M:

<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2013/05/nuspec.xsd">
  <metadata>
    <id>MobileApps.Auth</id>
    <version>0.1.1</version>
    <title></title>
    <authors>Jonas Rembratt</authors>
    <owners>Jonas Rembratt</owners>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <description>bla bla</description>
    <summary></summary>
    <releaseNotes></releaseNotes>
    <copyright></copyright>
    <language></language>
    <dependencies>
      <group targetFramework=".NETStandard2.0">
        <dependency id="Xamarin.Forms" version="3.1.0.697729" />
        <dependency id="System.ValueTuple" version="4.5.0" />
      </group>
    </dependencies>
  </metadata>
</package>

Strange, I create NetStd nugets all the time and have not seen that problem on VS4M... How is the nuget package physically laid out? (i.e. If you unpack the nuget and manually add a ref to the .dll does it work fine in the referenced project?) — SushiHangover, Aug 15 '18 at 14:39
The NuGet is packed with tons of libs, for no real reason as far as I can see. Yes, I can unpack the .dll from the NuGet and reference it successfully but if I just add the NuGet in the conventional way I get loads of CS1703 ("Multiple assemblies with equivalent identity have been imported: ..."). Is there a way to avoid having the NuGet crammed with unnecessary packages or to resolve those conflicts? — Jonas Rembratt, Aug 16 '18 at 07:18
_rels (empty folder) [Content_Types].xml lib netstandard2.0 MobileApps.Auth.dll (my lib) (+ 114 other dlls) MobileApps.Auth.nuspec package services metadata core-properties 5bd1f861cd8a425f854c073a4a5f3e0e.psmdcp — Jonas Rembratt, Aug 16 '18 at 07:36
It is the highly sensible outcome. A library can only be .netstandard when *everything* it uses is standard. There is nothing standard about xamarin forms, such a library could only ever be used in a xamarin project. — Hans Passant, Aug 16 '18 at 07:46
Cheers Hans. So, if I get you correct here what you're saying is: When targeting Xamarin with a NuGet package stick with PCL? Also, since the NuGet is referencing Xamarin.Forms it also supports monoandroid81 and xamarinios10 which makes it incompatible with Netstandard. Is that how I should read the error message? — Jonas Rembratt, Aug 16 '18 at 07:49
The lib/netstandard2.0 directory looks OK. NuGet should allow the package to be installed into a .NET Standard project. What does the MobileApps.Auth.nuspec contain after you extract it from the .nupkg? — Matt Ward, Aug 16 '18 at 14:09
@MattWard Which .nupkg do you mean? I edited the OP with the .nuspec from the .nupkg built with VS4M. — Jonas Rembratt, Aug 17 '18 at 04:58
Yeah, the one from inside the .nupkg. Looking at the contents of the .nupkg that should be fine in a .NET Standard project. There is no reference to monoandroid or xamarinios in the .nupkg. Is perhaps an old version of the .nupkg cached in your local NuGet package cache (~/.nuget/packages)? — Matt Ward, Aug 17 '18 at 10:28
Please see my answer below. It was too difficult to write as a comment. — Jonas Rembratt, Aug 17 '18 at 12:38

score 0 · Answer 1 · answered Aug 17 '18 at 12:38

0

Ok, here's the latest outcome from my experiments with NuGet/VS4M/VS2017. One problem seemed to be that VS4M included 113 libs in the NuGet package so I wanted to see if that was the problem or not. I first tried to simply renamed the .nupkg file into .nupkg.zip on the Mac, then unpack it, then remove the .nupkg, then remove the 113 libs in lib/netstandard20 leaving only my own dll in there. I then simply compressed the folder again into "MobileApps.Auth.nupkg.zip" but it seems Finder won't take kindly to then simply removing the ".zip" suffix. So, I simply moved the .zip over to Windows and removed the ".zip" suffix there before moving it back to MacOS. In the end I'm left with a .nupkg that in essence looks just like the one I generated with VS2017 (see OP), that is a package that contains only my own .dll file.

This works.

So, the problem now is that:

This leaves me with having to go through a tedious process of manually removing all unecessary .dll files from my NuGet package whenever I re-generate it. Is there really no way to configure the 'nuget' build to exclude these libs in the first place, like VS2017 does?
Why didn't it work when I built the .nupkg file on VS2017 and then tried to use it with my projects in VS4M?

answered Aug 17 '18 at 12:38

Jonas Rembratt

1,550
3
17
39

How are you building the NuGet package with VS Mac and VS 2017? – Matt Ward Aug 18 '18 at 13:27
1

Not able to reproduce 1 nor 2. I created a new .NET Standard 2.0 project in VS 2017. Went into project options and enabled generate package on build (which adds a GeneratePackageOnBuild property to the csproj). Installed the Xamarin.Forms and System.ValueTuple NuGet packages. Then build the .nupkg by building the project. Copied that to the Mac. That installs without any errors into a .NET Standard 2.0 project in VS Mac. Also building the project on the Mac does not add any other assemblies into the lib folder of the NuGet package apart from the project's main assembly. – Matt Ward Aug 18 '18 at 13:41
On VS4M I simply check the "Create NuGet Package when building the project" and fill out the metadata. I haven't really found any other options (are there any?). On VS2017 I do the same: Tick the "Generate NuGet package on build" and fill out the required metadata. – Jonas Rembratt Aug 20 '18 at 06:08
@MattWard I assume you also added NuGet.Build.Package (NuGetizer-3000)? – Jonas Rembratt Aug 20 '18 at 06:23
So, something, somewhere is causing VS4M to add 113 dlls to my .nupkg for some odd reason. – Jonas Rembratt Aug 20 '18 at 06:26
I tested your steps on a colleagues Mac and I get the same result there: 113 extra dlls gets added to the .nupkg. – Jonas Rembratt Aug 20 '18 at 06:38
1

No I did not use NuGetizer 3000. I just used VS 2017 and enabled the generate package on build. – Matt Ward Aug 20 '18 at 08:08
@MattWard : I did some more experimenting and it turns out that Nugetizer 3000 is the culprit. It appears that it's needed for the "Create NuGet Package when building the project" feature of VS4M. I tried removing it and, like I've mentioned before, no package gets built with the project. But if I actively use the "Create NuGet Package" from solution's context menu it works fine. Seems Nugetizer is needed for the automatic build for some reason while it's not really needed as such, to create packages. Does the "Build-NuGet-with-project" feature work for you (on VS4M) without Nugetizer 3000? – Jonas Rembratt Aug 20 '18 at 11:31
Setting the GeneratePackageOnBuild property to true in the .NET Standard project's .csproj file `true` was enough to get the .nupkg being generated with Visual Studio for Mac. – Matt Ward Aug 20 '18 at 18:50
@MattWard I can confirm this too. Although, the property is not automatically added/set when you tick the checkbox in Options like it's supposed to. At least for me it isn't. – Jonas Rembratt Aug 22 '18 at 13:12
Visual Studio for Mac does not add GeneratePackageOnBuild it will add a PackOnBuild which is NuGetizer specific. Visual Studio 2017 on Windows adds that property. Unfortunately there is a disconnect here between the two packaging models supported in the IDEs. – Matt Ward Aug 22 '18 at 15:28
@MattWard Cheers Matt. You've cleared up the confusion quite well. Any plans on bridgeing this disconnect? – Jonas Rembratt Aug 22 '18 at 20:03
I have opened an issue on the VS Mac bug tracker for differences in behaviour compared with VS 2017 for .NET Standard projects. This is internal but links to the developer community forum post and this StackOverflow post. – Matt Ward Aug 22 '18 at 21:15
@MattWard Thanks Matt. If you want the credit then please summarize the situation as a reply and I'll mark it as the answer. – Jonas Rembratt Aug 23 '18 at 09:23

VS for Mac unable to add .NET Standard NuGet

1 Answers1