1) I have few dll which has been developed using .net framework version 4.5.2 and VS2013 those dll used in winform application .net version 4.5.2. now developing a new winform application where i will use .net core 6 and VS 2022.

please guide me all how could i make those dll compatible for .net core 6 winform project?

2) another question is that we heard that .net core application run on linux & Mac OS. does it mean that if i develop a winform application using .net core 6 then does it run on linux & macOS?

3) we used a popular library called MoreLINQ for our winform application. if we are switching to .net core based winform application then can we use this library in .net core. please see this url https://nugetmusthaves.com/package/MoreLinq.Core and guide us.

thanks

You do not want to use MoreLinq.Core as it is depreciated, use this one .

does it mean that if i develop a winform application using .net core 6 then does it run on linux & macOS?

please guide me all how could i make those dll compatible for .net core 6 winform project?

You need to create new versions of the old DLL/class project, they will not work with .net core 6, Also, take a look at the new structure for .NET Core project files, nothing even close to the old structure.

Seems the editor did not format my post correctly

<Project Sdk="Microsoft.NET.Sdk">  
    <PropertyGroup>  
        <TargetFramework>net6.0</TargetFramework>  
        <ImplicitUsings>enable</ImplicitUsings>  
        <Nullable>disable</Nullable>  
    </PropertyGroup>  
    <ItemGroup>  
      <None Remove="readme.md" />  
    </ItemGroup>  
    <ItemGroup>  
      <Content Include="readme.md" />  
    </ItemGroup>  
    <ItemGroup>  
        <PackageReference Include="ConfigurationLibrary" Version="1.0.1" />  
    </ItemGroup>  
    <ItemGroup>  
        <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="6.0.8" />  
    </ItemGroup>  
</Project>  
 For your DLL's, you will need to create .NET Core projects and copy code from the old projects into the new .NET Core projects. Frameworks before .NET Core are not compatible with .NET Core.     
 No you can not directly use Windows code under linux and IOS as what is in Windows is not in the other two and vis-versa. See Cross-platform mobile development in Visual Studio    
 Yes you can use MoreLinq under .NET Core projects. Also, there may be improvements in .NET Core 6 that you may not need MoreLinq for or there may be methods that collide between MoreLinq and .NET Core 6.    
						
while .net core allows creating apps that run on windows, linux and macOS. you must use libraries that run the selected platforms.  
in your case WinForms is a windows only library, so an application using it will only run on windows.  It the same on MacOs, if you use UIKit for the UI, the app will only run on MacOs (though you can male a general to run on MacOs and IOS).  
to make cross platform apps, use a web technology like asp.net of the new cross platform Maui UI.  
						
If I may add a comment here. We wanted to use a whole load of complex code written over many years in .Net Framework, but have a .Net Core front end that would allow for future proofing the look and feel of the product and maybe now we could even update it to use Maui, but we won't have yet updated (had time to update) the .Net Framework 4.8 code.    
I don't know if anyone might find it useful, but what we have done is this:    
 Create .Net Core projects (front end .Net Core WinForms in our case) and associated DLL projects containing most of the functionality (allowing us to change WinForms for Maui for instance)    
 Create a new .Net Framework project (a simple EXE with a hidden interface running in the background at the same time as your main .Net Core interface), containing references to old .Net Framework DLLs that would take too long at this point in time to update and test.    
 Create a .Net Standard DLL that both projects can reference, this being a communication DLL to allow simple messages (ints/strings etc.) to be sent over Pipes (enum defined here too for the message type, and consider using threads for no blocking).    
Voila! You can now use your old Framework DLLs via the quick Pipe messaging DLL. You just set up the code once to handle the communication so that you can do a standard call, and the data is returned to a standard place. Use of Delegated Callbacks are handy to get data back to the higher level interface places.    
Like I say, this is not for everyone, but once it's set up it just works. It's all standard tested technology. We just simply don't have the time at the moment to update and test this quite complex .Net Framework code. This was relatively quick to set up.    
												
@Harsch Manuel       

Hiya.    
I guess the main thing you need to get working first would be the Named Pipes. See this documentation here:    

https://learn.microsoft.com/en-us/dotnet/api/system.io.pipes.namedpipeclientstream?view=net-6.0    

Get that into a '.Net Standard' DLL project with 2 classes. One Client class to send and one Server class to listen and receive.    
Then in the same '.Net Standard' DLL project create a class.     

That class will contain an enum definition. The enum will be the message type something like 'public enum eMessageType { Start, Stop, Login, ... whatever best desribes the message/data being sent }.    

Add properties to the class like string sParam1, string sParam2, int iParam1, int iParam2, bool bVal1, bool bVal2, int[] iArrVals, string[] sArrVals. Keep these generic and simple so that you can send anything across. Also include a property of the eMessageType.    

Now you can create an object on the fly to pass around that describes the data being passed around and the data itself.    

You'll need to pack and unpack that data accordingly.    
More to follow...    
												
@Harsch Manuel       

Then set up 2 simple EXE projects to test this out. One .Net Core and one .Net Framework.     

Make the .Net Core one the visible interface (your choice - WinForms/Maui/WPF etc.).    

Make the .Net Framework one run purely in the System Tray for example (use AppContext) so that you never really see it.    

It could also be set up as a Windows Service, this would be dependant on how you are deploying the final delivery.    

Give both projects a reference to the .Net Standard DLL. The Class type you set up above will be (and need to be) recognised by both the EXE projects.    

You then need to call a 'SendMessage' function in the Client Class (Core) that turns your object into a byte array to stream across to the listening server pipe (Framework). And vice versa.    
Do with that data as you wish and think about threading to send the data so you don't block and hold up the interface. But then you might want it to wait... your call.    
If you need further help, let me know, I'd be happy to help by email maybe? Probably best not to take up space with my rambling nonsense in this forum ;o)