We Keep Coding

Adding .NET Core Multi-target to a .NET Framework library

I have a .NET Framework library with NuGet package dependencies. This library is consumed exclusively by .NET Framework projects. Some of them by local project references, and most through NuGet. I publish the library to a private NuGet server.
A few projects have cropped up using .NET Core based infrastructure, and I would like to make my standard library available to these projects. I am not switching any of the existing infrastructure to .NET Core. I don't want to introduce .NET Core dependencies into every existing .NET Framework project. I have noticed that when I install certain multi-targeted libraries, sometimes they include "netstandard" or something like that -- and install lots of dependencies. These are unacceptable and get immediately uninstalled from .NET Framework projects.
Is it possible to multi-target my .NET Framework (4.72 if it matters) project to .NET Core as well, while still producing native .NET Framework libraries? I can copy and paste all the code in my library into a netcoreapp3.1 project, install NuGet dependencies, and that code runs fine. However, I don't want to port this library to .NET Core, and then multi-target it back to .NET Framework. As far as I am aware, that is not the same as having a native implementation. I just want to be able to use the library in a .NET Core app without copying and pasting the entire library, and letting the versions get out of sync. The less ceremony the better.
My csproj file doesn't have a <TargetFramework or <TargetFrameworks> property. It has a <TargetFrameworkVersion>v4.7.2</TargetFrameworkVersion> property.
Is what I'm trying to do possible? I can't tell from the documentation I have read.

Why does a dotnet Core App with a reference to a classic .Net project works and compiles [duplicate]

I'd really like to start using .NET Core and slowly migrate applications and libraries to it. However, I can't realistically upgrade my entire code base to use .NET Core and then go through the process of testing and deploying a plethora of applications in production.
As an example, if I create a new .NET Core application and try to reference one of my .NET Framework projects I get the following:
The following projects are not supported as references: -
Foobar.NetFramework has target frameworks that are incompatible with
targets in current project Foobar.NetCore.
Foobar.NetCore: .NETCoreApp,Version=v1.0
Foobar.NetFramework: .NETFramework,Version=v4.5
Is it possible to create a new .NET Core application and reference my existing .NET Framework libraries? If so, what's the process for doing that? I've spent hours going through Microsoft's documentation and searching their issues on GitHub, but I can't find anything official on how to achieve this or what their long-term vision is for this process.

Old question, but with the release of .NetStandard 2.0 and .netcore 2.0 and vs2017.3, the game has changed.
You can use the Full .NET Framework (TFM) with .NetCore 2.0, but how?
In Visual Studio 2017.3, you can reference the Full .NET Framework (any version) directly from within a .NetCore2 project.
You can build the .NetStandard2 class library and reference your TFM. Then reference your .NetStandard2 library from your .NetCore2 project.
For example, referencing json.net net45 from .NetStandard2.
Browse to the folder and select version net45 (not netstandard1.3)
See the dependency in the image below, no yellow warning as you see.
Even if a Nuget library is not ready to be ported to .Netstandard 2, you can use any API in the library that is compliant to net461.
Quoting for the .NET Core 2/Standard 2.0 announcement with links:
.NET Core 2.0 is able to freely reference libraries that have been built for .NET Framework up to version 4.6.1
However, some libraries may fail at run time if they try to use API methods that aren't available on .NET Core
Reference: .NET Core App target .NET framework 4.5.2 on Linux
A need to use third-party .NET libraries or NuGet packages not available for .NET Core
So only in cases where the libraries or NuGet packages use technologies that aren't available in .NET Standard/.NET Core, you need to use the .NET Framework.
Reference: Choosing between .NET Core and .NET Framework for server apps
You can now reference .NET Framework libraries from .NET Standard libraries using Visual Studio 2017 15.3. This feature helps you migrate .NET Framework code to .NET Standard or .NET Core over time (start with binaries and then move to source). It is also useful in the case that the source code is no longer accessible or is lost for a .NET Framework library, enabling it to be still be used in new scenarios.
Reference: Announcing .NET Core 2.0

Yes, we are currently attempting the same thing. The trick is to make sure that you are supporting the same .NET frameworks. Inside your project.json file, make sure the framework matches the framework of the project you wish to include. For example:
"frameworks": {
"net46": { --This line here <<<<
"dependencies": {
"DomainModel": {
"target": "project"
},
"Models": {
"target": "project"
}
}
}
},
FYI: You might need to change the framework of your .NET Core or your older projects to achieve this. .NET Core can be changed just by editing the project.json file as seen above. You can so the same in .NET projects by right clicking the project and opening properties. Change the framework level there.
Once you have matched the two project frameworks then you should be able to include them. Good Luck!

We delayed migrations as long as could as it seemed daunting as first. But we got an insistent client who wanted to migrate ASAP.
So we migrated their Fintech Web App developed on .NET Framework 4.8 Web Forms to .NET 6 Razor Page. Our team scoured though hundreds of online resources & spoke to Microsoft Tech Support before we started the project. Hope the high-level walkthrough of our journey help you plan your migrations.
Our .NET Framework Website consisted of 1 .NET Web Forms project and 12 Class Libraries.
Here is how we did it.
Refactored the .NET Framework 4.8 Web Forms code
We ensured that the Web Forms code behind did not have a single line of service or business logic code. When we did find some business logic code in the web forms code behind, we refactored it, by moving it to the class libraries.
Created new .NET Standard projects
We created a new .Standard 2.0 Class library project for every .NET Framework 4.8 Class Library. If the original project was called "FintechProjectName.StockMarketClient", we named the .NET standard project "FintechProjectName.StockMarketClient.Standard".
Copied all files from .NET framework to .NET standard
We copied all the class files from .NET framework to .NET standard projects. We then removed all the .NET framework class libraries from the solution and added references to the new class libraries. All projects compiled on the 1st try itself and all our test cases too passed with minor changes.
Create new .NET 6 Web App Project
We created a new .NET 6 Web App Project. We had to entirely redo the front-end as there is no direct path for migrating Web Forms to Razor Pages. This was the only project which took us about 1 month to migrate.
Reference .NET standard class libraries in the new .NET 6 website
We copied all the .NET Standard libraries to this new solution containing the Razor Pages web site. Added the references and got it to work.
Move from .NET Standard to .NET 6 class libraries
Once the new website was up and running, with all test cases passed, we did the last step in the process which was the simplest. Created .NET 6 class library projects for each of the .NET standard libraries and named the projects appropriately. Copied all class files from .NET standard projects to their corresponding .NET 6 projects. Then we removed the .NET Standard libraries and added references to the new class libraries.
Overall project timelines were about a month and a half, most of it spend on Razor Pages implementation using the same html design.
Note:
If you are using any 3rd party library which does not have a .NET standard or .NET 5 version, then you are out of luck. You will need to find a replacement nuget package and recode your application to use this new library.

In my case with .net6 referencing framework 4.8 library ( both winforms), the trick seems to be to add the reference to the framework dll as a shared reference.

Why referencing a .Net standard nuget package in a .Net 4.7.2 project import a lot of .Net core lib?

I'm having a .Net 4.7.2 application, in which I want to reference the package OpcFoundation.NetStandard.Opc.Ua. This project as a list of dependencies for .Net 4.6 that is quite small.
But when I install it, I get like 50+ additional packages to install. Is there a way to reduce this? I feel that a lot of thoses classes are already existing in the full .Net project(System.Threading.Tasks/Timer/...).
Thank you

If you look at many of these types (which are supplied by .NET Standard packages, not .NET Core), you'll find that the specific version that's used against .NET 4.7.2 will be an empty assembly just containing lots of TypeForwardedTo attributes pointing right back at the full-flavour .NET Framework.
So you still end up using the exact types you always would have done. There's just extra indirections which allows .NET Standard to work with both .NET Framework, .NET Core and other .NET Standard implementations.

Can I use any old arbitrary WIndows library in a .net core web app?

I just can't understand why I can't use an old library in a .net Core app targeting Windows and the full .net framework (I don't care about multi-platform).
Just trying to understand the limits here. I don't want to hit a wall after investing too much into it.
Steps followed:
Create a new .Net core web Application
Added PetaPoco from NuGet (just an example)
Can't use the library

From a comment from you on a deleted answer to this question
It's not about this particular reference. I just want to understand why I can't use an arbitrary Windows DLL. (I don't care about multi-platform) – Eduardo Molteni
It appears you are not too concerned why this specific project is not working (the deleted answer you commented on covered that quite well and if it was not deleted I would have up-voted it) but why in general you can't use a .NET Framework DLL in a .NET Core project.
Here is a diagram showing the layout of the ".NET ecosystem"
Things built for .NET Framework can't use DLLs built specifically for .NET Core, and things built for .NET Core can't use DLLs built specifically for .NET Framework because they are two "siblings" in the hierarchy.
Both .NET Framework and .NET Core can use .NET Standard libraries in their projects because .NET Standard is the "parent" of both the framework and core. Many newer NuGet packages now release versions that target .NET Standard so the library can be used with both versions. See the below chart to see what version of the .NET Standard library is compatible with various platforms. netstandard libraries are forward compatible so something that is compatible with 1.5 (like .NET 4.6.2) is also compatible with versions 1.0-1.4

easiest way to convert .NET project from 4.5 to 4.0?

I have a .NET application that I built in 4.5, which has references to a bunch of libraries that were built in 4.5, which themselves have references to 4.5, etc. A user group that I'm trying to distribute the application to is having problems running the executable because they have 4.0 installed; in particular, they're getting a MissingMethodException:
Method not found: 'System.Type System.Runtime.InteropServices.Marshal.GetTypeFromCLSID(System.Guid)'.
Because we may have trouble getting each user upgraded to 4.5 (as none of them have admin permissions on their machines and this would require a separate upgrade request for each user), I'm looking at finding an easy way to rebuild the project as 4.0. This seems to require that I rebuild every library and its referenced libraries in 4.0; is there an easier way to do this than going through each library one by one and building a 4.0 version? I'm thinking maybe like a one-click option for "Rebuild all referenced libraries in target framework" or something like that.

If you have dependencies on .Net 4.5 DLLs then you will need to also get .Net 4.0 versions of those if you want to successfully downgrade your project. A .Net project can only reference .Net DLLs up to the same version of .Net as the referencing assembly.
The easiest way to do this is to use something like NuGet to manage your dependencies. Note that when you change the target framework version of your project in VS you will need to uninstall and re-install dependencies with NuGet as NuGet does not automatically do this for you when you change the target framework version.
Of course if all the dependencies are to your own code and you aren't publishing this through a dependency management system like NuGet you will need to downgrade all your other code to .Net 4.0 as well

When I use Visual Studio, I right click on the project, change the framework, fix the References and recompile. Usually straight forward.

Please, have a look at this MSDN page to correctly switch your project to a lower target framework without problems! It is a little bit outdated for what concerns versions, but the process is the same described!

This is based on my experience. I had an application initially created in .net framework 4.5 but I wanted to convert it in .net framework 4.0. I created new project initially created 4.0 and then I did copy and paste of all the forms and controls of my previous application and it works. Framework 4.5 is using Aero2 and 4.0 is Aero... Good Luck :)