4

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?

mbabramo
  • 2,573
  • 2
  • 20
  • 24
  • What are you trying to do? I.e. which features in Azure are you trying to interact with? The package you mention is very old! .NET Core apps can only use libraries which are either compatible with .NET Standard or .NET Core. I'm pretty sure that this package is neither – silent Jul 18 '19 at 12:44
  • @silent .NET Core apps can use .NET Framework libraries using something called asset target fallback, which generates NU1701. The .NET Core SDK 2.0 started using .NET 4.6.1, which has expanded to "net461;net48" in .NET Core 3.0, but can be modified by any project using MSBuild properties. – zivkan Jul 18 '19 at 13:07
  • @silent I am trying to use RoleEnvironment.IsAvailable from Microsoft.WindowsAzure.ServiceRuntime. There does not appear to be a Microsoft.WindowsAzure.ServiceRuntime available. – mbabramo Jul 18 '19 at 13:56
  • is this related to Web Roles (or something similar)? I'm not sure that's even still supported on Azure today - or at least you probably don't want to use it for new projects. Can you post a bit more what it actually is you are trying to build? – silent Jul 18 '19 at 14:20
  • @silent Thanks again -- very helpful. All I am trying to do is figure out whether my console app performing a long calculation is running on Azure or on a local machine, as I have some different behavior in the two cases. As a workaround, I could make two different versions of the app, one for azure and one for local machine. – mbabramo Jul 18 '19 at 14:45
  • How do you run your app in azure? Web Jobs? In containers? – silent Jul 18 '19 at 14:52
  • @silent Service Fabric. (When running on my own machine, I sometimes use Service Fabric and sometimes just a console app. It's actually the underlying shared library code that needs to know whether it's in service fabric.) – mbabramo Jul 18 '19 at 15:27
  • @silent I can see some alternatives to what I was trying to do here: https://stackoverflow.com/questions/28998566/azure-websites-roleenvironment-isavailable-equivalent. Thanks again for your help. – mbabramo Jul 18 '19 at 15:44

1 Answers1

2

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.

zivkan
  • 12,793
  • 2
  • 34
  • 51
  • Thank you. I already use the blob package you specify. But I can't find an official package for Microsoft.WindowsAzure.ServiceRuntime, which contains the RoleEnvironment.IsAvailable API that I need. I installed the specified package because when I typed RoleEnvironment.IsAvailable, Visual Studio suggested installing Microsoft.WindowsAzure.ServiceRuntime. Perhaps this suggestion is out-of-date, but I haven't figured out an alternative. – mbabramo Jul 18 '19 at 13:59
  • Searching the [Azure .NET SDK](https://github.com/Azure/azure-sdk-for-net) for ServiceRuntime doesn't return any results, so whatever you're using that API for, there's probably a different way to do it now. – zivkan Jul 18 '19 at 14:30
  • I am setting this as the "correct answer" -- in my case, the real point was the one in the comment, i.e. I was using an API that Microsoft hasn't deprecated but doesn't expect us to use anymore. – mbabramo Jul 18 '19 at 15:45