What is the status of .NET Standard for the Microsoft.Azure.Mobile.* NuGet packages? Looking at the release notes, the last release that mentions .NET Standard was from quite some time ago and references the outdated project.json. Also, when I install v0.16 to a .NET Standard 2.0 library I get the following message:
Package 'Microsoft.Azure.Mobile 0.16.0' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETStandard,Version=v2.0'. This package may not be fully compatible with your project.
Looking at ~/.nuget/packages/microsoft.azure.mobile/0.16.0/lib, it seems PCLs are still being used. Any plans to update this?
Hi, our SDK is compatible with .NET standard by just adding a line to the csproj: https://docs.microsoft.com/en-us/mobile-center/sdk/getting-started/xamarin#3-add-the-mobile-center-sdk-to-your-solution.
Last time we tried to migrate our own SDK code to .NET standard, everyone complained it broke their PCL build and we never found the cause, so we need to let time pass for .NET standard to be adopted in people's apps. Pretty much everyone contacting us still uses packages.config and old PCL.
I tried following those instructions and got the following error in the Package Console in Visual Studio for Mac:
PackageTargetFallback and AssetTargetFallback cannot be used together. Remove PackageTargetFallback(deprecated) references from the project environment.
I checked and AssetTargetFallback does not appear in my csproj, so not sure what to make of it.
Update: It appears there is now an implicit AssetTargetFallback included somewhere. I am experimenting with the DisableImplicitAssetTargetFallback option mentioned in the above link. Assuming it works, you'll want to update the documentation in the link you sent me.
Can you try <AssetTargetFallback>$(AssetTargetFallback);portable-net45+win8+wpa81;</AssetTargetFallback> or <AssetTargetFallback>portable-net45+win8+wpa81</AssetTargetFallback> ?
I was just typing as you commented. :-) Yes, it seems that using AssetTargetFallback directly as you suggest also works. That said, now every time I open the project I get the message: "Packages restored with warnings".
Package 'Microsoft.Azure.Mobile 0.16.0' was restored using '.NETPortable,Version=v0.0,Profile=Profile111, .NETFramework,Version=v4.6.1' instead of the project target framework '.NETStandard,Version=v2.0'. This package may not be fully compatible with your project.
Package 'Microsoft.Azure.Mobile.Analytics 0.16.0' was restored using '.NETPortable,Version=v0.0,Profile=Profile111, .NETFramework,Version=v4.6.1' instead of the project target framework '.NETStandard,Version=v2.0'. This package may not be fully compatible with your project.
So compatibility via the PCL fallback comes at a cost.
In any case thank you for your help. I personally will wait until there is proper .NET Standard support to avoid these warnings.
Yeah, I can confirm this workaround. But the warnings that get generated are annoying.
.NET standard is the way forward, everyone is already switching, and I really think you should too.
People that are sticking to obsolete formats should have to implement workarounds, not us following the current guidelines
This is in our backlog, but we can't communicate if and when the feature will be completed.
@irreal @nathanielcook Can you try the prerelease version 0.17.0-r0002-5c783ea which uses .NET standard? We are also trying to contact some PCL users for validation.
Seems to work ok for me! (I only use Mobile Center Analytics at the moment.) Note to those with iOS app extensions: Add the mobile center NuGet references to the iOS app extension projects as well, assuming your extensions reference your .NET Standard library that references the Mobile Center. Otherwise you can get a "Could not compute a complete dependency map for the project" warning.
@irreal @nathanielcook released in official 0.17.0 version.
Most helpful comment
Yeah, I can confirm this workaround. But the warnings that get generated are annoying.
.NET standard is the way forward, everyone is already switching, and I really think you should too.
People that are sticking to obsolete formats should have to implement workarounds, not us following the current guidelines