Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Learn more about Collectives

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams

Microsoft recently announced .Net 6.0 as major version. I didn't find any reference where we can use older .NET framework (> 4.7.*) references in .net 6.0 project?

Say, a .NET 6 project will have dll reference of .NET Framework 4.7.1 for windows application?

You can try . There is some support for attempting to load .NET Framework assemblies into .NET Core. But if the .NET Framework assembly does something or uses something which .NET Core doesn't happen to support, you're out of luck. If those .NET 4.7.1 assemblies actually target .NET Standard <= 2.0, then you're fine: they can run both on .NET Framework, and also on .NET Core – canton7 Nov 17, 2021 at 13:44 What's causing you to want to do this? Did you lose the source code? Or are you just wanting the DLL to target .NET Framework because you have another .NET Framework app that needs to consume the DLL in addition to the .NET 6 app? – mason Nov 17, 2021 at 13:46 @mason, We already have a legacy project in .net 4.7.2 and we need to share it in Web API and existing projects. – Jatin Dave Nov 17, 2021 at 14:01 Could work, .net5 for example has forwarders for mscorlib, System, System.Core, System.Configuration, System.Data, System.Drawing, System.Net, System.Numerics, System.Runtime.Serialization, System.Security, System.Web, System.Windows, System.Xml, WindowsBase and a few more. They transparently map the framework type+assembly to the equivalent .NETCore type. Very thorough testing is required to ensure that everything maps as expected, it tends to be a lot easier to just recompile the assembly. – Hans Passant Nov 17, 2021 at 15:47 @mason, The legacy project also have references of c++ projects. So actually it is a mixed code in both c++ and c# project references. I am not sure converting those projects in .NET standard helps? – Jatin Dave Nov 18, 2021 at 11:55

The Problem

Assemblies that "target" (are compiled against/for) .NET Framework (1.0-4.8) may use APIs (types, methods) that are not present in .NET Standard or .NET Core.

So if you have a project that targets .NET Standard or .NET Core, and you want to add a reference to an assembly that targets .NET Framework, it may be that the assembly will throw exceptions at runtime, because it's missing method overloads or types. Those types are present in the Framework DLLs, but not in the .NET Core runtime assemblies.

Now if you know (through interpreting the code or through testing, preferably both) that the Framework-targeting assembly doesn't use APIs that are missing from .NET Standard or .NET Core, you're fine (for the difference, see What is the difference between .NET Core and .NET Standard Class Library project types? ).

The fix (but not really)

If it's an assembly that's chucked in a lib folder in source control, you can add an assembly reference:

<Reference Include="../lib/path/To/Dll.dll" />
If it's a NuGet-packed dependency, you can install it and override the warning:
<PackageReference Include="Some.Framework.Package" Version="1.0.0" NoWarn="NU1701" />
The fix (for real this time)
Recompile the assembly to target .NET Standard 2.0, and package and distribute that through NuGet.
This is a question with a complex answer.
Let me blunt. It is highly likely the answer to your question will be no, it can't be done, but that is because you have a very specific library in mind. The real answer is that it depends on the library in question, but chances are mostly geared towards this not working.
Yes, you can load .NET Framework assemblies into .NET Core 5 and 6.
However, depending on what that library does, and probably more important, what dependencies it has aka other libraries it wants to drag with it, it might not work properly for any sizable complex library.
There are classes that doesn't exist in .NET 5+, or even just single method overloads or properties. Depending on the exact parts of .NET Framework you access, it may in fact just be missing outright in .NET 5+.
There is more information here.
Your best option is probably to try to:
Re-compile the library for your particular .NET version (be it 5 or 6)
Re-compile the library targeting .NET Standard 2.1, as .NET 5+ is compatible with that
However, you might in fact just get into the exact same problem with that re-compile as you will have to deal with those changed bits. But, then at least you would have more knowledge about what would and wouldn't work, and you have a chance to fix it.
If it's not your library to change, either replace it, or try and hope for the best.
In general, no you can't. They're not really designed to be compatible. .NET Core and the subsequent .NET 5 and 6 are based on a complete re-write of .NET.
There may be some chance of things which work using the .NET Framework Compatibility mode but it's far from guaranteed.
If you want reliable, cross-framework compabitility for your libraries between .NET Framework and .NET Core / 6 you can try to target your libraries at .NET Standard
You can have a .NET 6 Core application calling into a .NET Framework 4.8 dll. It took me a while to figure out how to do it, but it can be done. I have created both console and web .NET 6 Core applications which call into some of my legacy .NET Framework 4.8 dlls. The process is as follows:
Create or open your .NET 6 Core solution in Visual Studio 2022 and add your legacy .NET Framework 4.8 dll to your .NET 6 Core solution.
Add your legacy .NET Framwork 4.8 dll as a reference to your top level .NET 6
Core Console or Web project.
Delete the "obj" and "bin" directories from your top level project via file explorer.
From the Visual Studio 2022 top level menu, select "Tools > Command Line > Developer Command Prompt". This should open a command line window with the current directory changed to that of your solution.
Run the command "dotnet restore" in the command window. This will re-create your "obj" directory and place a "project.assets.JSON" file into the "obj" directory which will reference your recently added .NET Frameowork 4.8 dll. If you fail to do this you will get a runtime error when you run up your application.
Rebuild and rerun your application. Your .NET Framework DLL should now load with no problems.
I'm not sure if the removal of the "obj" and "bin" directories is always essential, however I have found that if you don't remove them, occasionally the "project.assets.JSON" file isn't generated properly and running fails. Removing them then re-running the command solves the problem.
                But how do you solve the problem that "a few technologies in .NET Framework that don't exist in .NET"?
– Graviton
                Jun 29, 2022 at 7:06
        
Thanks for contributing an answer to Stack Overflow!
Please be sure to answer the question. Provide details and share your research!
But avoid …
Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.