[.NET Migration Guide Revamp] [Backlog] Backward Compatibility

There doesn’t seem to be a .net core-specific doc about this support (or at least I wasn’t able to find it) but I did find a doc that talks about .Net Framework compatibility which has a section for campatibility of .Net components (aka libraries) which holds true for .Net core as well: https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/version-compatibility#version-compatibility-for-components

Note that other parts in that doc mention that apps compiled for one framework can run on a higher version of .net framework, which as I said in my previous reply, in .net core we call roll forward and it is something we don’t recommend. Here is another doc talking about roll forward and how we recommend for apps to be recompiled in those cases: https://docs.microsoft.com/en-us/dotnet/core/releases-and-support#runtime-roll-forward-and-compatibility

Thanks,

---

Let me ask one more question.

Is there any documentation that shows official support for this scenario?
If it is not specified in the documentation, it would be great if you could include it in the documentation as I know this is a scenario that is often asked.

---

Hi, Thank you for your prompt and courteous reply!
It was nice to have a clear confirmation that this scenario was officially supported. I can now answer my customer with confidence.

---

Yup. This is officially supported.

---

What you are trying to do is a supported scenario. By this I mean that it is considered supported to consume a library that targets netcoreapp3.1, from an application that targets net5.0 or net6.0. I believe that what you were referring to as a "major version backwards compat" is for a different scenario, which is to try to run pre-compiled apps that targeted one framework (e.g. netcoreapp3.1) on a newer runtime that has a different major version (e.g. net5.0). This scenario is not supported, we refer to it as roll forward and that one we can't guarantee that you won't hit errors at runtime. That said, seems like that is not the case in your scenario, and you are simply compiling an app that targets net5.0, and consuming a library that targets a lower framework, which as explained before, is a supported scenario.

---

For .NET Standard, this is definitely supported, as it’s the value of it. For targeting a specific TFM, from the API level we expect it to work (notwithstanding documented breaking changes). At the hosting/loader level, that’s not my area of expertise.

---

Hello, experts

One of my customers has a question about the .NET backward compatibility.
The question is "Is there a compatibility issue when calling a DLL created with .NET Core 3.1 as the target framework from an application created with .NET 6 or .NET 5 as the target framework?".

When I tested it on my end, I was able to call the methods of the DLL class without any problems in any of the patterns.
Application TFM DLL TFM Result Loaded runtime version
.NET 6 .NET Core 3.1 Success .NET 6
.NET 5 .NET Core 3.1 Success .NET 5
.NET Core 3.1 .NET Core 3.1 Success .NET Core 3.1

My understanding was that .NET Core backward compatibility works fine if the major versions are the same, otherwise it doesn't.
I also understand that if it is compiled with .NET Standard, it will work fine with .NET Core / .NET 5.

Q1. Is it an officially supported scenario for DLLs to be called by applications with different major versions of the runtime?
Q2. Is there any documentation on backward compatibility between .NET Core / .NET versions?

- Referenced document -
https://github.com/dotnet/runtime/issues/35556
https://github.com/dotnet/runtime/discussions/40782
https://dotnet.microsoft.com/platform/support/policy/dotnet-core

Hope my question make sense. If you know about that, please let me know.

Thank you,