I am converting a .NET Framework 4.7.1 class library to .NET Standard 2.0.
The library consumes a number of Nuget packages, all of which are available for both .NET Framework and .NET Standard and these packages include the WindowsAzure.Storage SDK.
The original .NET Framework class library compiles and runs correctly, but the .NET Standard library fails to compile, due to missing APIs (and some different method signatures) on the WindowsAzure.Storage SDK.
For example, CloudBlockBlob has a DeleteIfExists method in .NET Framework but not in .NET Standard.
The API documentation lists this method (and all the others that are broken in .NET Standard) but doesn't appear to mention any version differences between target frameworks. Did I miss something relevant here?
Is it normal that some .NET Standard Nuget packages have gaps in their APIs?
Is there a solution or a workaround for this (apart from re-writing the code that consumes these APIs)?
Thanks, in advance.
As per Peter Bons mentioned, In the nuget package WindowsAzure.Storage, there are only task based methods, so DeleteIfExistsAsync for .net core / .net standard.
Please use the new nuget package for azure storage. For blob storage, you can install Microsoft.Azure.Storage.Blob, version 9.4.0 or above, which does support sync / async methods.
The change log is here:
And here is a simple test with .net standard project with Microsoft.Azure.Storage.Blob, version 9.4.0 or above installed. Both sync / async methods are there.
Related
We are using NotificationHubs version 1.0.9 with .NetCore 2.0 and .Net Framework 4.7.
At compile time, we get this warning:
"Package Microsoft.Azure.NOtificationHubs 1.0.9 was restored using '.NETFramework, version=4.6.1' instead of the project target framework '.NETCoreApp, version=2.0. this package may not be fully compatible with your project."
Everything is still built, but at runtime when this call is invoked:
RegistrationDescription hubRegistration = await hubClient.CreateAppleNativeRegistrationAsync(device.DeviceToken); //hubClient is NotificationHubClient
We get this error:
Has anyone encountered this before and have any idea how to fix it?
At compile time, see this warning: "Package Microsoft.Azure.NOtificationHubs 1.0.9 was restored using '.NETFramework, version=4.6.1' instead of the project target framework '.NETCoreApp, version=2.0. this package may not be fully compatible with your project."
The Microsoft.Azure.NotificationHubs package requires .Net Framework 4.5 Full Profile. And here is a feedback Microsoft.Azure.NotificationHubs add support for .NET CORE.
AFAIK, if you create the ASP.NET Core Web Application with the target framework at .NetCore 1.0 or .NetCore 1.1, you could edit your *.csproj and change the TargetFramework to net461, then you could install and use Microsoft.Azure.NotificationHubs 1.0.9.
While for .NetCore 2.0 MVC, after you create the project, it would reference the Microsoft.AspNetCore.All 2.0.0, and this package supports netcoreapp2.0. I assumed that you could leverage Notification Hubs REST APIs and follow the git sample azure-notifications Send REST to access your notification hub for a workaround.
A preview version of a .NET Standard compatible NuGet is now available. It will allow using Notification Hubs with .NET core.
According to a Microsoft Product Manager a new version of the .NET SDK supporting .NET Core will be deployed very soon.
cf this question
But no mention on Feedback Microsoft site. I would recommend to vote for this feature
Since Microsoft has released .NET Core 2.0 for Azure Functions a few days ago, I'm trying to understand how to create a new Functions project in VS2017 targeting .NET Core.
I've tried many configurations and still ended up with .NET 4.7.
Did anyone manage to create a new Function targeting .NET Core?
Thanks.
This is supported with the 1.0.5 release of the Microsoft.NET.Sdk.Functions package.
In your Azure Functions Project, do the following:
Update the Microsoft.NET.Sdk.Functions package version to 1.0.5
Right click on your project, click the Edit <projectname>.csproj option and modify the TargetFramework element value to netstandard2.0
This will should generate .NET Standard 2.0 assemblies with all the artifacts created by the Azure Functions tooling.
As of today I have been able to target .Net Standard 2.0 in a "reasonably" intuitive way and without editing any .csproj files.
You need a reasonably recent version of Visual Studio. I'm using Visual Studio Professional 15.5.3 (although I would guess that community would work).
You need to have the Azure development workload installed. This will install an extension called Azure Functions and Web Jobs Tools.
So far so plain vanilla. There were 2 additional bits that were to me not at all intuitive but ended up being very easy to do - easy when you know how!
You need to make sure that the Azure Functions and Web Jobs Tool is 15.0.31114.0 or greater - that's when they added .net core 2.0 support (see https://github.com/Azure/Azure-Functions/blob/master/VS-AzureTools-ReleaseNotes.md). You can update this using Tools/Extensions and Updates, or see https://marketplace.visualstudio.com/items?itemName=VisualStudioWebandAzureTools.AzureFunctionsandWebJobsTools
Even when you've done that, Visual Studio is a tiny bit weird about letting you create Azure Functions that target .net 2.0. When you go File/New Project, nothing has changed in the list of available project types, and if you select Azure Functions, the list of Frameworks just shows .NET Framework *, no .NET Standard, no .NET Core.
But if at this point you persevere and select Azure Functions, you then get a new dialog I hadn't seen before, which allows you to select Azure Functions v2 Preview (.NET Core).
Now, when I then look at the project properties, it turns out it is targeting .NET Standard 2.0, which in turn seems to contain Microsfot.NETCore.Platforms (1.1.0). So is this .net core 2.0 or not? Not quite sure but its' good enough for my purposes so now going to tuck into some coding.
Cheers!
For now, it's a manual process. You need to create .NET Standard 2.0 library, add function.json manually and run it with core tools.
the package Microsoft.NET.Sdk.Functions does not yet support .NET Standard 2.0 class libraries. This is the package that identifies a project as Functions project to Visual Studio and generates function.json from attributes during build.
You can still author C# class libraries that target .NET Standard 2.0, but you must use a manually-authored function.json. The templates for C# class libraries aren’t yet available in the Core Tools, but you can get a sample from GitHub.
from Develop Azure Functions on any platform
Update: 1.0.5 version of SDK should now support it, as mentioned by Fabio.
I'm porting my applications from VS2015 to VS2017 and trying to figure out the right migration path. I'm also moving my web services to .NET Core to take advantage of deploying to Linux or Windows servers. I see that I have the option of creating base libraries in .NET Standard or .NET Core. Is there any advantage to a .NET Core library or should I create the base libraries in .NET Standard by default?
Practically speaking, .NET Standard 2.0 is the intersection of .NET Framework 4.6.2(-ish) and .NET Core 2.0.
If you build a library targeting .NET Standard 2.0 then your library can be consumed by .NET Framework libraries and applications, as well as .NET Core libraries and applications. That's the advantage of Standard.
But there are several types/members that have been added to .NET Core which aren't part of .NET Standard. If you want to use something like the new CertificateRequest class you'd need to explicitly target .NET Core.
.NET Core allows new things to get to users faster than .NET Framework does, so the general tradeoff will always be ".NET Standard => more places; .NET Core => newer things".
.Net Standard is just package with interfaces with can be used to provide compatibility across .Net Framework, .Net Core and others
I wouldn't choose a .NET Core library. The differences are in the referenced libraries:
the .NET Standard library references the netstandardX.X NuGet meta-package
the .NET Core library references the netcoreappX.X NuGet meta-package
The netcoreapp package also includes some .NET Standard packages, but also a bunch of .NET Core App specific packages (including libuv. Don't know why a library needs libuv.)
So the .NET Standard library is for cross platform and the .NET Core library just for .NET Core
According to Support and Retirement Information for the Azure SDK for .NET and APIs, SDK 2.6 introduced support for .NET 4.6. None of the listed SDKs explicitly mention 4.6.2 though the sister article Install .NET on a Cloud Service Role includes an installation script that explicitly installs .NET 4.6.2, implying that it is supported for web/worker roles.
When I attempted to upgrade my solution from .NET 4.5.1 (using Azure SDK 2.8) to .NET 4.6.2, I also modified my RoleProperties.txt file which included the following lines:
TargetFrameWorkVersion=v4.5.1
RoleTargetFramework=v4.5.1
to
TargetFrameWorkVersion=v4.6.2
RoleTargetFramework=v4.6.2
which resulted in the following error after calling cspack.exe:
Unsupported .Net Framework v4.6.2
I tried changing the 4.6.2 to simply 4.6 and that similarly failed.
So my questions are:
How do you correctly target .NET 4.6.2 using cspack.exe?
Is it necessary to set those properties to 4.6* or is it safe to leave them at 4.5.1 since cspack.exe doesn't complain?
I was inspecting the change log of Windows Azure Storage nuget from here. I do not get the usage of CoreCLR, PCL and WinRT.
For instance
Changes in 7.2.0 :
All (CoreCLR): NetStandard target framework changed to netstandard1.3
All (PCL): Removed support for PCL in favor of NetStandard GA release
...
Changes in 7.1.2 :
...
All (WinRT): Fixed a bug where HttpClient default timeout caused unhandled TaskCancellation exceptions.
...
A simple search on google tells that CoreCLR is a .NET execution engine and WinRT stands for Windows Runtime. I do not know what PCL is.
So what is the importance of these in change log in simple terms?
Those represent versions of the package capable of running on different versions of .Net:
WinRT is used in Windows Store apps, it uses a trimmed version of .Net
PCL is short for Portable Class Library, the old approach of targeting multiple versions of .Net from a single library
NetStandard is a new approach of targeting multiple versions of .Net, that came along with .Net Core, the new modular cross-platform version of .Net
CoreCLR is the runtime used by .Net Core, though marking changes to NetStandard version of the library as "CoreCLR" is confusing