NuGet软件包应支持哪些.NET版本以最大化其可用性和功能？

Question

TL;DR:

• Given: I wrote a library with relatively portable functionality (for example, Left.Pad.©.dll ). I want to make it available though NuGet.

• Requirement: If somebody wants to use my library on any version of any platform on any version of any operating system with any updates installed by writing code in any IDE or any code editor, they should be able to do it.

• Question: What is the minimum set of NuGet target frameworks to achieve that?

• Bonus question: If there're any "dead" frameworks which shouldn't be targeted, or something else which should be taken into consideration when choosing target frameworks, you can mention it too.

---

Thoughts (old version):

NuGet packages support multiple .NET Framework versions and profiles , for example, a package can provide net20, net30, net35, net40, net45, sl3, sl4, sl5 etc. versions. However, assuming there aren't always differences in the functionality of a package , providing a lot of versions would be a waste of build time and package size and cause unnecessary complexity. On the other hand, providing a package just for the lowest supported Framework version could cause missing functionality, for example .NET 4 supports in-process side-by-side execution of multiple CLR versions, but previous versions don't, so this feature will be lost if just a version for .NET 3.5 is provided (I'm not sure; I've never used it and don't know the details). If a PCL version is provided, the logic is simple I assume: just exclude versions which PCL covers.

Answer 1

At the moment of writing, the easiest way is to create a .NET Standard 1.1 project. It supports

• .NET Core 1.0 and higher
• .NET Framework 4.5 and higher
• Mono, Xamarin, Windows Phone and more...

So pretty much all of the modern platforms. If you want to support older platforms, ex. .NET Framework 3.0, add this as a separate "folder" in NuGet. This way, newer .NET Core applications can still use your package.

---

More information

.NET Standard acts a replacement for PCL . The lowest .NET Framework you can target with PCL is 4.0, which isn't much lower than 4.5 with .NET Standard 1.1 (thus won't make your package much more accessible).

PCL also doesn't seem to support .NET Core, while .NET Standard nearly supports all platforms:

Also note that according to Microsoft, only .NET Framework 3.5 SP1 and .NET Framework >= 4.5.2 are currently supported . All other .NET Framework versions already reached end of life and won't get any updates. Windows Phone is also dead and Silverlight isn't getting anywhere too.

As @Lex Li mentioned in the comments, .NET Standard 1.1 has a very low API surface, which means there are maybe some important APIs missing. Because of that, most NuGet packages use a higher .NET Standard version. It is recommended to use the lowest .NET Standard version possible.

So with .NET Standard 1.1, you will support a huge majority of the modern frameworks. Sadly, I couldn't find any .NET Framework distribution statistics...

---

If you really want to make your package available for every platform , take a look at the possible target platforms for NuGet . I think you need atleast net11 and netstandard1.0 , maybe add some Silverlight and .NET MicroFramework support...

Answer 2

Solution of 2018

Based on given asnwers and assuming no dependency on platform-specific technologies (like System.Drawing, ASP.NET or WPF; in which case just target the platform you can and be done with it):

1. netstandard1.0 — netstandard2.0 Start with .NET Standard 1.0 and go up until you reach maximum functionality.

   This should cover:

   • .NET Framework 4.5
   • .NET Core 1.0
   • Mono 4.6
   • Xamarin.iOS 10.0
   • Xamarin.Android 7.0
   • Windows Universal 10.0
   • Windows non-Universal 8.0 (up to .NET Standard 1.2)
   • Windows Phone 8.1 (up to .NET Standard 1.2)
   • Windows Phone Silverlight 8.0 (up to .NET Standard 1.0)
     

   If you can't reasonably implement the library within the limits of relatively small .NET Standard 1.0–1.2, the last three points are likely to be excluded. If you still need them, see points below.

   .NET Standard 1.5+ increases the requirements on the versions of the frameworks and operating systems, so multi-targeting .NET Standard versions may be required for maximum compatibility.

2. portable-net40+* The next major point is obsolete PCL. Its .NET Framework 4.5+ versions aren't relevant as they're mostly covered by .NET Standard. If you want to support Windows Phone 8 and non-Universal Windows Store 8, you should do it through PCL, unless you're limited by API, in which case you'll have to add platform-specific targets.

   If you don't need any of additional platforms and .NET Framework 4.0 provides some useful additional functionality over .NET 3.5, you can target it directly, not through PCL.

   This should cover:

   • .NET Framework 4.0
   • Windows non-Universal 8.0
   • Windows Phone 8.0
   • Windows Phone Silverlight 8.0

3. net20 — net35 If you want to support ancient desktop Windows versions (like Windows XP) and unupdated more recent Windows versions (like Windows Vista+ with .NET 3.0+), you should add support for desktop .NET Framework targets directly. Note that as of 2018-01-01, the lowest supported .NET is 3.5 SP1, so going lower than that is probably unnecessary and will likely limit API available to you too much with no real benefits.

   This should cover:

   • .NET Framework 2.0-3.5
   • Windows XP

4. There're other platforms, namely Xamarin-specific ones, Tizen, .NET Micro etc. They can be accessed only by targeting them directly.

   This should cover:

   • Everything else

TL;DR

Something like netstandard1.1 + portable-net40+win8 + net35 covers every relevant platform.

Solution of the future

When old .NET versions completely die, only .NET Standard should remain. Well, unless Microsoft invents yet another cross-platform unification technology, like it already did with .NET, .NET PCL, .NET Standard...

TL;DR

Use the lowest netstandard you can.

Answer 3

You should target .net framework 2.0 and above. The decision should be based on the platform the application will run in production. .net 2.0 comes included in Windows 2008 server (SP2 and onward) and people still use it extensively in production. Ref https://en.wikipedia.org/wiki/.NET_Framework

Answer 4

If you want it to be used not only on Windows - .NET Standard is the way to go. Target latest as question of what libraries to use comes early in a project and is rarely revisited and new projects tend to use recent versions of frameworks and libraries.

• What .NET Standard versions are supported by what versions of other frameworks (GitHub).

• What .NET Framework versions are supported by which Windows Server versions (MS Docs).

• Server version share in SpiceWork network . It is not a representation of global data , but it's best data I found to get idea of Windows Server market share.

  

• Info on Linux prerequisites for .NET Core versions (MS Docs).

You can find recent market shares of user devices based on internet usage easily.

See the numbers, pick platforms you want to reach and cross-reference it with which versions of .NET are available on them.

Answer 5

Targeting .Net Standard would give your nuget package the luxury of being employable in .NET framework ,.NET core, mono, Xamarin, Universal Windows Platform, and Windows Phone projects.

See the following taken from this answer

To decide which version of .Net standard you should target use the following table:

Source .

Looking at the above table I would recommend going with .Net standard 1.0 if you care about Windows Phone Silverlight or .Net standard 1.2 if you do not.

Also, as far as I noticed lots of people that chose .net core are actually using .net core 2.0 so you might want to create a seperate nuget version for them with .net standard 2.0.

About the second part of your question, even if a specific framework is dead that does not mean that it would go away instantly, it would be still used for several years before it is completely dead, simply moving to different options takes time.

Another thing that I would take into consideration is the common used libraries, like Masstransit , EPPlus , and the commonly used IOCs, etc.. I would take a general look on the frameworks supported by them and follow because many undergoing projects might be driven by such libraries.