What is .NETStandard1.7?

[zipswich]

In VS2017, the options for targets are: .NETStandard1.0, 1.1...1.7. What is .NETStandard1.7? I am unable to find it in the official document.

[davidfowl]

It's a temporary place holder until netstandard 2.0 is ready in the toolchain (specifically nuget)

[zipswich]

Thank you for the prompt explanation. What is the ramification of this temporary place holder? In other words, what would be the consequence if I used it?

[Petermarcu]

It doesn't really exist yet. It was a preview that didn't ship and is being used temporarily for building things within the dotnet repos. I wouldn't use it as it's likely to never ship and instead roll into .NET Standard 2.0.

Are there certain API's in 1.7 you are looking for? Is that why you are trying to use it?

[zipswich]

Thank you for the clarification. It may explain the trouble that I am having with using .NETStandard1.7 .

Here is my situation. I am migrating apps from WinRT and Universal for W8.1 to UWP or Xamarin. For example, the Windows version of a Universal project uses three libraries: PCL shared by all kinds of apps (desktop, mobile and web), Universal library shared by W8.1 and WP8.1, and Windows library shared by W8.1 apps. Now, I am porting them to two libraries: a portable library targeting .NETStandard, and a UWP class library. I want to move the contents of the UWP class library to the portable library as much as possible. It would absolutely ideal if I could eliminate the UWP class library so that all apps (UWP, Xamarin iOS, and Xamarin Anroid) will share only one library: the portable library targeting .NETStandard.

[zipswich]

I changed the target to .NETStandard1.6, but building the app still result in the same errors.

[Petermarcu]

@yizhang82 , any ideas on what would cause errors like those?

[zipswich]

I have just noticed that the reference to the portable library had a yellow triangle icon. I removed it, and tried to add it again, then got the error: Unable to add a reference to project 'ClassLibraryAllPlatforms'. The current proejct's target is not one of or compatible with the targets of Portable Library project 'ClassLibraryAllPlatforms'. Does this mean that .NETStandard1.6 does not support UWP? I am still trying to figure out what the right arrows mean exactly in the .NET Platforms Support table.

[Petermarcu]

UWP is 1.4 so you are right, at least this problem is because UWP doesn't support 1.6.

[zipswich]

I retargeted the library to .NETStandard1.4, and the yellow triangle is gone. Unfortunately, I am still getting the same errors. Just in case it is a problem of the app, I created a brand new UWP app without adding a single line of code. I added a reference to the portable library targeting .NETStandard1.6, the built the app. Over 10 thousand errors still occurred:

2>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\VisualStudio\v15.0\AppxPackage\Microsoft.AppXPackage.Targets(1924,5): warning APPX1707: No implementation file was provided for the .winmd file 'E:\Users\Hong\Documents\Hong\RandD\VSNET\Xamarin\ClassLibraryAllPlatform\bin\Debug\Windows.Foundation.UniversalApiContract.winmd'. To generate registration information in the app manifest, specify the 'Implementation' metadata on the .winmd reference item in the project file. 2>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\VisualStudio\v15.0\AppxPackage\Microsoft.AppXPackage.Targets(1924,5): error APPX1704: The .winmd file 'Windows.Foundation.UniversalApiContract.winmd' contains type 'Windows.Web.IWebErrorStatics'. The use of the Windows namespace is reserved. 2>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\VisualStudio\v15.0\AppxPackage\Microsoft.AppXPackage.Targets(1924,5): error APPX1706: The .winmd file 'Windows.Foundation.UniversalApiContract.winmd' contains type 'Windows.Web.IWebErrorStatics' outside its root namespace 'Windows.Foundation.UniversalApiContract'. Make sure that all public types appear under a common root namespace that matches the output file name. 2>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\VisualStudio\v15.0\AppxPackage\Microsoft.AppXPackage.Targets(1924,5): error APPX1704: The .winmd file 'Windows.Foundation.UniversalApiContract.winmd' contains type 'Windows.Web.WebError'. The use of the Windows namespace is reserved. 2>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\VisualStudio\v15.0\AppxPackage\Microsoft.AppXPackage.Targets(1924,5): error APPX1706: The .winmd file 'Windows.Foundation.UniversalApiContract.winmd' contains type 'Windows.Web.WebError' outside its root namespace 'Windows.Foundation.UniversalApiContract'. Make sure that all public types appear under a common root namespace that matches the output file name. 2>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\VisualStudio\v15.0\AppxPackage\Microsoft.AppXPackage.Targets(1924,5): error APPX1704: The .winmd file 'Windows.Foundation.UniversalApiContract.winmd' contains type 'Windows.Web.AtomPub.IAtomPubClient'. The use of the Windows namespace is reserved.

[weshaggard]

@zipswich do you get those errors when you don't consume the netstandard library? It looks like a potential SDK issue and not related to consuming a standard library. As @Petermarcu pointed out though you will not be able to consume anything higher then a netstandard1.4 library right now in UWP applications.

[zipswich]

No, I do not get any problem without referencing the library. I created the brand new empty UWP app, and built it without any problem, then added the reference, built it again, and got 10K + errors. I removed the reference, then built the app again, and succeeded without any errors. The empty app actually runs on a Windows 10 machine without any problem. The building only generates the following warnings:

1>C:\Program Files (x86)\MSBuild\15.0\Microsoft.Common.targets\ImportBefore\Microsoft.NetNative.ImportBefore.targets(25,3): warning MSB4011: "C:\Program Files (x86)\MSBuild\15.0\.Net\.NetNative\15.0.24208\Microsoft.NetNative.Settings.targets" cannot be imported again. It was already imported at "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Microsoft.Common.targets\ImportBefore\Microsoft.NetNative.ImportBefore.targets (25,3)". This is most likely a build authoring error. This subsequent import will be ignored. [E:\Users\Hong\Documents\Hong\RandD\VSNET\Xamarin\App1\App1.csproj]
1>C:\Program Files (x86)\MSBuild\15.0\Microsoft.Common.targets\ImportAfter\Microsoft.Net.CoreRuntime.ImportAfter.targets(17,3): warning MSB4011: "C:\Program Files (x86)\MSBuild\15.0\.Net\CoreRuntime\Microsoft.Net.CoreRuntime.targets" cannot be imported again. It was already imported at "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Microsoft.Common.targets\ImportAfter\Microsoft.Net.CoreRuntime.ImportAfter.targets (17,3)". This is most likely a build authoring error. This subsequent import will be ignored. [E:\Users\Hong\Documents\Hong\RandD\VSNET\Xamarin\App1\App1.csproj]
1>C:\Program Files (x86)\MSBuild\15.0\Microsoft.Common.targets\ImportAfter\Microsoft.NetNative.ImportAfter.targets(16,3): warning MSB4011: "C:\Program Files (x86)\MSBuild\15.0\.Net\.NetNative\15.0.24208\Microsoft.NetNative.targets" cannot be imported again. It was already imported at "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Microsoft.Common.targets\ImportAfter\Microsoft.NetNative.ImportAfter.targets (16,3)". This is most likely a build authoring error. This subsequent import will be ignored. [E:\Users\Hong\Documents\Hong\RandD\VSNET\Xamarin\App1\App1.csproj]

[weshaggard]

What type of class library project did you create? I assume you created a Portable class library that you retarget to .NET Standard and selected netstandard1.4, is that correct?

If that is what you did unfortunately the UWP projects don't support libraries that are referencing "NETSTandard.Library" packages which is what that tooling references. We are still doing a lot of tooling changes and which will make this a lot better but right now it is pretty rough. I would suggest you build a UWP specific library, or a older PCL style class library.

[zipswich]

The culprit appears to be Newtonsoft.Json NuGet package. To test this, I created a brand new portable library targeting .NETStandard1.4, and added its reference to the empty UWP app. Everything was fine. I added NewtonSoft.Json NuGet package through the NuGet manager to the empty portable library, built the empty app, 10K+ errors occurred.

It looks like VS 2017 has a problem. It should prevent Newtonsoft.Json from being added to a portable library targeting .NETStandard1.4.

[weshaggard]

@srivatsn this seems like another issue with the older netstandard class library project. What is our play for that project type?

[srivatsn]

@Pilchie and I have talked about removing that project type entirely to not cause confusion. We haven't acted on that yet though

[zipswich]

I have found another culprit - Nito.AsyncEx.Coordination NuGet package. Stephen said yesterday that NuGet package is for .NETStandard. Now, I am wondering if I can add any NuGet package besides the ones automatically added by VS.

[weshaggard]

I would try adding those nuget package references directly to the app or a UWP specific class library.

[zipswich]

The migrated app has finally started running after removing the last culprit in the portable library references: Windows.Foundation.UniversalApiContract. This reference was added by the IntelliSense when I tried to use Windows.UI.Xaml.Data.IValueConverter. I think the biggest lesson here is that VS 2017 cannot be trusted to filter out any NuGet packages or references for portable libraries that would break at least UWP apps.

[zipswich]

@weshaggard I am sorry but I have just realized that I missed your question. I think that by now that you have already realized that the answer to your question regarding the portable class library type is "Yes". It is a portable library retargeted to .NETStandard. I hope the project will survive with the current configuration and benefit from the improvement you folks are doing.

[weshaggard]

@zipswich it sounds like you have figured out your issue. I'm going to close this now if you have further questions around tooling please file one at https://github.com/dotnet/sdk.

[zipswich]

Yes, I am all set for now. Thanks a lot for all the help, @weshaggard
Look forward to new improved releases.