What Non-4.* .NET App Versions play well with Standard?

Question

I am building an MVC Web API (Service) with Views returned in specific cases. As an architectural decision, I've been directed to NOT build the service project in .NET Framework 4.*. Rather, I am to attempt .NET 5.0 first, and then Core 3.1 if 5.0 doesn't work.

This service project in my solution will depend on a few class library projects, call them DataLibrary, ComplexLibrary, and DocLibrary. DataLibrary will depend on a Nuget package of Oracle, be it ODP or Oracle Managed Data, in order to query an Oracle database via an Oracle Package on that database. DocLibrary will depend on a Nuget package of Aspose Word & Aspose PDF. ComplexLibrary will depend on Oracle AND Aspose.

Here's my dilemma:

1. Aspose Word's latest stable release (21.6) will report that it is compatible with 5.0 and Standard 2.0, but not .NET Core.
2. Oracle Managed Data reports that it is compatible with Standard 2.1 or Standard 2.0, but not 5.0 or .NET Core.
3. My own libraries have reported that they are not compatible with my API .csproj if...

3a. The API is 5.0 and the libraries are .NET Core or .NET Standard

3b. The API is Core 3.1 and the libraries are .NET Standard.

Since my compile script naturally requires a run of Nuget to retrieve all the necessary dependencies, I cannot get a clean compile because I seemingly have no combination of versions for my WebAPI and libraries that satisfy each others' compatibility needs. Since Standard libraries are the only common .NET version that satisfy the needs of both Aspose & Oracle, What available version for my WebAPI (i.e. I don't believe that Standard is an option for anything other than a class library) is compatible with .NET Standard libraries?

Thanks.

Answer 1

Well, don't I feel silly.

Turns out, the issue wasn't incompatibilities within Aspose, Office, .NET Core, 5.0, and Standard, but a failure of a prior version of NuGet to handle the different versions.

While my VS 2019 install was able to compile the whole solution effectively, my local install of NuGet was not. This was due to VS2019 likely using the most up-to-date version as of this post (5.9.#), while my locally installed version was 4.9.#. Thus, VS was able to sail through while my compile script kept failing at the NuGet stage (which I have included prior to the actual compile.) Once I ran a NuGet update, everything was good to go.

Long story short: KEEP YOUR NUGET VERSION UP-TO-DATE!!!