3

Consider there is a class library which targets following frameworks:

  • net45
  • .NET Standard 2.0
  • .NET Standard 2.1

That is my configuration:

<TargetFrameworks>net45;netstandard2.0;netstandard2.1</TargetFrameworks>

Let's say this library is a public NuGet package and I don't know which runtime versions consumers will ever use.

How can I as vendor to test my library with these 3 target frameworks? I know for testing I have to pick runtimes in my test project. That part is clear and easy. For instance for my library I could pick runtime net45 for framework net45.

But then what about testing for netstandard2.0 or netstandard2.1? How could I technically achieve that I test against netstandard2.1? For instance runtime netcoreapp3.1 supports netstandard2.0 and netstandard2.1 - but which one will be then chosen as both are compatible?

Maybe it is the wrong term to say to test against these 3 target frameworks? Maybe it is rather to test for specific runtimes. That I don't know and try to answer that for me.

Heretic Monkey
  • 11,687
  • 7
  • 53
  • 122
Thomas Purrer
  • 131
  • 5
  • Does this answer help: https://stackoverflow.com/a/44478400/982149 ? – Fildor Feb 16 '21 at 13:38
  • 2
    Note that recommendations are kind of off-topic, so I edited your question to concentrate on the "how". No one's going to answer with a method they don't recommend :). – Heretic Monkey Feb 16 '21 at 13:58

2 Answers2

0

I'd rather say test with specific runtimes. For example, you could test .NET Standard 2.0 using the .NET Core 3.1 runtime.

But from my perspective, it is not your task to test all different runtimes claiming to be compatible with .NET Standard 2.0. It is the runtime's job / responsibility to adhere to the specification (e. g. .NET Standard 2.0).

You have to ensure that the code you're producing is compatible to the specification. For this, both the compiler and tools like .NET Portability Analyzer will help.

From the perspective of testing, you can use testing projects with multiple runtimes.

mu88
  • 4,156
  • 1
  • 23
  • 47
0

You are right about testing your code on all available runtimes, that your code could potentially be run. There are indeed implementation differences between NETFramework and NETCore, even from one NETCore version to another, so it's definitely not wasted time. You can do that using multi targetting with any of the big unit testing platforms (xUnit.net, NUnit, MSTest).

Likewise, you can also test your code using Nuclear.Test, which will figure out all the relevant runtimes for you and invoke your tests. All you need to do is point your test assembly at the same target frameworks as your library. The testing API is a little different from what you're used to, but I believe that the benefits are worth it. There is a useful manual and an explanatory blog post about all the features. A code documentation is coming in the near future, but the links should get you started easily.

There is currently a flaw in the assembly resolving mechanism, when a NuGet package is targeted that doesn't quite follow the versioning scheme of NuGet packages. Fortunately, this doesn't happen too often, and it will be fixed in the next release.

MikeLimaSierra
  • 799
  • 2
  • 11
  • 29