Using .NET5 binaries with full framework applications

[hosathota]

Not able to find a conclusive answer to following scenario. I am developing a .NET5 library which should be usable with .NET Core 3.1 and .NET5. It works as expected. But my requirement is to make this library available to applications written in .NET Framework 4.8 also. Going by various articles, it looks like that is supported. But my package is not usable from .NET Framework 4.8 application.

I am aware of tag and I can include like the following in the .csproj file:
net5.0;net48

My understanding is, its not needed to include net48 once the net5.0 is included. Is this a correct assumption? If it is correct assumption, then is there anything else needed to be done.

Any help is appreciated.

Thanks
Vishwa

[davidfowl]

The way to think about it is that you're multi-targeting your library so that it can run in multiple places, .NET Framework 4.8, .NET Core 3.1 and .NET 5. It's inaccurate to say that you're writing a .NET 5 library that runs on .NET Core 3.1 as that doesn't always work.

Going by various articles, it looks like that is supported.

It's not supported. You can either build a .NET Standard 2.0 library that runs everywhere, or you can target each of those platforms you want to support my changing your project file to specify them individually.

See https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/cross-platform-targeting for more information.

[hosathota]

Hi david,
thanks for your quick response. Yes, I was the aware of the link you shared.

I am referring to this link
https://devblogs.microsoft.com/dotnet/introducing-net-5/

and the below line
"Produce a single .NET runtime and framework that can be used everywhere and that has uniform runtime behaviors and developer experiences."
We are at present on .NET Core 3.1 and we have separate package for .NET Framework 4.8 also. Based on the above link, I was thinking that If we target .net5.0, it can be used from a .NET Framework 4.8 applications also. Are you saying that we should continue to have one package for .NET Core 3.1, one for .NET Framework and additionally one more for .net5? If that is the case, what is special about .NET 5?

Some of our customers are using .NET FW 4.8 and some are on .NET Core 3.1(netstandard 2.1). With .NET5, we were thinking of unifying two separate packages into one .NET5 package. If that is not the supported or recommended scenario, is there a better way to enable our existing .NET5 users to move to .NET 5? Should they simply upgrade their .NET 4.8 applications to .NET 5 and use our .NET 5 package/library?

Thanks
Vishwa

[davidfowl]

Based on the above link, I was thinking that If we target .net5.0, it can be used from a .NET Framework 4.8 applications also

No that's incorrect. You can't use .NET 5 binaries on .NET Framework 4.8 safely.

Are you saying that we should continue to have one package for .NET Core 3.1, one for .NET Framework and additionally one more for .net5?

You should have a single package with multiple target frameworks.

If that is not the supported or recommended scenario, is there a better way to enable our existing .NET5 users to move to .NET 5?

I'm not 100% clear what it means for you to move to .NET 5? Are you talking about a library or application?

Should they simply upgrade their .NET 4.8 applications to .NET 5 and use our .NET 5 package/library?

Unfortunately, our docs aren't clear here but .NET 4.8 applications can't be simply upgraded to .NET 5. .NET 5 is a rebranded .NET Core and doesn't share a lineage with .NET Framework.

.NET Core 3.1 -> .NET 5 (these are compatible)
.NET Framework 4.8 -> .NET 5 (these are NOT comptible)

To share code between .NET Framework 4.8 and .NET 5 you can either:

• Use .NET Standard 2.0
• Multi-target .NET Framework 4.8 and .NET 5 explicitly

cc @terrajobst

[terrajobst]

The message from the blog post is really about concentrating our efforts on .NET 5 as the foundation for all .NET workloads. Yes, I understand that the animation/PowerPoint somehow paints the picture that .NET Framework is somehow brought into .NET 5, but that's not the case. This has already happened, starting in .NET Core 2.0 where we added the Windows Compatibility Package and .NET Standard 2.0, where we added 20k of the most used .NET Framework APIs. This was pushed even further in .NET Core 3.0 where we added WinForms and WPF. But we announced in October last year that we're done with porting .NET Framework functionality to .NET Core.

As far as versioning rules go: you generally can't use newer from older. For example, you can't build a .NET Framework 4.8 library and consume it from .NET Framework 4.5. We have picked the version of .NET 5 deliberately to make it bigger than both .NET Framework as well as .NET Core to avoid this confusion moving forward. You can consume .NET 5 from .NET 5 and future versions, but you can't consume .NET 5 libraries from .NET Core 3.1 or .NET Framework 4.8.

As @davidfowl said, you can continue to build a single binary that can run everywhere by targeting .NET Standard 2.0. If you need to additionally expose functionality/implement behaviors that uses .NET 5 features you can multi-target for .NET Standard 2.0 and .NET 5.0. Or you can can decide to drop support for older platforms. I expect that applications will generally go the latter route (because you can always go self-contained with .NET 5) and popular libraries generally going with the former (because there is still a lot of code on .NET Framework out there).