I have installed NuGet package Microsoft.WindowsAzure.SDK in a .Net Core 3.0 app. This results in the following warning:
Warning NU1701 Package 'Microsoft.WindowsAzure.SDK 2.9.0' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETCoreApp,Version=v3.0'. This package may not be fully compatible with your project.
I receive a similar error when attempting to install the package into a .Net Standard 2.0 project.
NuGet lists the Microsoft.WindowsAzure.SDK package as having no dependencies. Another question addressed what was then the absence of the package; the package now exists but it produces this warning.
Of course, I could suppress this warning. I understand (see, e.g., this answer) that when this message arises, the code often will work just fine, given the similarities of .Net Framework 4.6.1 (and later) and .Net Core 3.0. Yet at other times, the application may fail at runtime.
It seems odd that a package critical for Azure would throw such a warning in a .Net Core project, and presumably the warning means something. Will the entire API continue to work in the .Net Core (or .Net Standard) project? Is there any documentation of what might not work?
NU1701 has nothing to do with dependencies, it's about the dlls that were selected in the lib/ folder of the package. If you look at the package (using fuget.org, or looking at the directory in your global packages folder, or downloading the nupkg from nuget.org and using NuGet Package Explorer or any other program that can open zip files), you'll see the dlls are directly under the lib/ folder, whereas usually dlls are under lib/<tfm>/. This is an old layout that NuGet doesn't encourage and considers incompatible with .NET Core. Therefore, it uses Asset Target Fallback to see if the package is compatible with .NET 4.6.1 and we consider it to be, even though the package isn't explicit about which .NET Frameworks it's compatible with.
Indeed, the package might fail at runtime, NuGet has no way of knowing, hence the warning. This is one of the reasons I really like the port-adapter-simulator design pattern. Create an adapter for blob storage, which also has the benefit of an API that's simpler for the rest of your business logic to use than the Azure SDK is. Write tests for the adapter and run the tests on netcoreapp3.0 and if the tests pass, you can be confident that none of the APIs your adapater uses will crash at runtime in production. Then you just need to make sure all the other code uses the adapter and not the Azure SDK directly. You can also see how it makes switching to a new package easy, in the rare times that needs to happen.
However, in this case you might notice that the Microsoft.WindowsAzure.SDK package has a latest version of 2.9.0 and was published in May 2016, so if you search a little, you'll find a package Microsoft.Azure.Storage.Blob with version 10.0.3 published in May 2019. This package has both .NET Framework and .NET Standard libraries, so if you use it, you won't get NU1701 warnings any longer. Similar for whatever other Azure APIs you use, they're all split into separate packages now, rather than one enormous SDK which most projects use less than 1% of.