We Keep Coding

TargetFrameworks in .NET Core

We are upgrading our project to .NET 6 from .NET Framework 4.5. We have a windows form application. Many of windows form commands has been depriciated in .NET 6. So to tackle this, I changed one of the Windows Forms project in the solution from:
<PropertyGroup>
<TargetFramework>net6.0-windows</TargetFramework>
</PropertyGroup>
to
<PropertyGroup>
<TargetFrameworks>net45;net6.0-windows</TargetFrameworks>
</PropertyGroup>
Now after changing this, I get the below error:
Project <another_project> targets 'net6.0-windows'. It cannot be referenced by a project that targets '.NETFramework,Version=v4.7.2'.
I understand why another_project is throwing this error message which is because the another_project is referenced in this Windows Form project and another_project's TargetFramework is .NET 6. So, I can change the TargetFramework for another_project to include .NET 4.5 as well.
But my question is, if I change this TargetFramework to TargetFrameworks and add multiple Framework there, does that mean my project is not upgrading to .NET 6 completely. Since it's using .net45 to complie/build in those cases, where it's failing to build in .NET 6. How does TargetFrameworks work??
I found the below link also, TargetFramework vs. TargetFrameworks (plural). But was not much helpful to understand this.

I'm assuming that you've upgraded your project files to SDK-style.
<TargetFrameworks>net45;net6.0-windows</TargetFrameworks> will effectively build your project twice - once for .NET 6.0 and once for .NET Framework 4.5.
(I'm not sure why your .NET Framework project is still targeting .NET 4.5 - I would have thought you should have retargeted it to 4.8 a long time ago...)
The output folders for these two targets will be:
For the DEBUG build:
\bin\Debug\net6.0-windows
\bin\Debug\net48
For the RELEASE build:
\bin\Release\net6.0-windows
\bin\Release\net48
Now if you want to reference one of those assemblies in another project, you're going to need to decide which to use, depending on the target framework for the dependent project.
In your case, it seems that you should be referencing the one in the "net6.0-windows" folder, so you should change your other project to reference that.
However, if you want the dependent project to ALSO be multi-targeted, you will need to change the hint path in the dependent project to use a compile variable to select the correct one.
For example, suppose your multi-targeted dependent project currently references a DLL using the following hint path:
<Reference Include="YourLibraryName">
path to referenced dll\bin\debug\net45\YourLibrary.dll
</Reference>
(Where "path to referenced dll" is whatever path is needed to locate the library.)
Clearly that will only reference the DEBUG Net 4.5 version of the library. You want it to reference the correct debug or release version and the correct .Net 4.5 or .Net 6.0 version. To do that, you can change the hint path to:
<path to referenced dll>\bin\$(Configuration)\$(TargetFramework)\YourLibrary.dll
At build time, $(Configuration) is replaced with the correct DEBUG or RELEASE string, depending on whether you're building DEBUG or RELEASE.
Similarly, the $(TargetFramework) will be replaced with the current build target, taken from the <TargetFrameworks>net45;net6.0-windows</TargetFrameworks> setting - either "net45" or "net6.0-windows".
Doing this will cause the correct DLL to be chosen from your multi-targeted project on which this project depends.
Note that this only applies to references using HintPath as above. If you're using project references, things would be different.
Also note that it's also possible (and maybe better) to create a NuGet package which will handle the dependencies etc properly, but that's a whole different story.

TargetFrameworks is used to build same project to multiple frameworks (so you have binary for each of them in output). It's usually used by libraries so they can be consumed by app targeted for different frameworks or, much less frequently, by apps, so they could be run on different machines.
I guess neither of theses is your cases. You just need to rework your app so it uses only features available in .NET Core.

Since you have added both net45 and net6.0-windows to your project it means that it should be compliable for both frameworks (i.e. it will be compiled twice, for each of the target frameworks), but you are trying to add reference to net6.0 project, which can't be used from net45. You need to either upgrade both to net6.0 only, or add net45 to the another_project.
Though usually it is another way around (compared to what you are trying to do), you use multitargeting for library projects (i.e. another_project in this case if I understand correctly) and keep one version for the executables (i.e. WinForms project should keep it's version).

Target Framework not showing older .Net versions in Visual Studio 2022

I installed Visual Studio 2022 on my PC. When I select the template "ASP.NET Core Web API" and try to choose the target framework, the dropdown is showing only the current framework .NET 6.0 (Long Term Support).
Why it is not showing the older versions?
I had planned to work on a .NET 5 version.

Open Visual Studio Installer, click Modify and check if you installed older versions of .NET

I did have the older .Net versions installed, and it still only showed 5.0 and 6.0, so the answer didn't help me. In the end, the culprit seemed to be the newer .csproj format; older projects I opened worked fine, and showed the versions from 2.0 to 4.8. Despite VS2022 having no issue with opening these solutions, I have yet to find a way to let it create them.
The old format starts like this:
<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="15.0">
The new one, however, doesn't have an xml header or namespace definition. It starts like this:
<Project Sdk="Microsoft.NET.Sdk">
Bizarrely, this new type of project file doesn't even seem to contain a list of files included in the project.
Just replacing the header doesn't work, though; the new format is too different, and the old format expects a lot of things to be auto-generated in the .csproj file concerning build type and targeted CPU.
In the end, the easiest solution was just to make a copy of an older project, manually generate a GUID for the project and plug that into the .csproj and .sln file, and then clean out the files and start from that.

I try to set in Unity С# Project framework 4.6.1 but it return to 4.7.1 after save the project

I use Unity 2019.4.2f1 and Rider 2019.2.3.
I tried to use a library NPOI, but it need framework version 4.6.1.
Ok, I had set the version 4.6.1 in the solutions Assembly-CSharp and Assembly-CSharp-Editor.
All right, it works. But next step I had save the project and get errors because... the framework in the solution becomes again 4.7.1.
Ok. I tried do it with Visual Studio 2019 and I got same result.
Ok. I tried to write set framework's version in the files Assembly-CSharp.csproj and Assembly-CSharp-Editor.csproj with v4.6.1. And I got same result.
Something automatically sets the version of the framework and I don't understand where is the shit.
WTF? Does anybody know anything about it?

Unity doesn't rely on csproj for compilation. csproj is only created for IDEs.
Theoretically you workaround by moving Rider package from whatever it is on your computer to Packages folder, it becomes your locally developed package, then you can change TargetFrameworkVersion https://github.com/van800/com.unity.ide.rider/blob/0a42b224e6191934884de084ccd59348742a2bc6/Packages/com.unity.ide.rider/Rider/Editor/ProjectGeneration/ProjectGeneration.cs#L83

Project X targets framework '.NETStandard'. The Entity Framework Package Manager Console Tools don't support this framework

I'm trying to create a EF 6.4 migration in my solution which has net472 projects and netstandard projects, and I'm getting the following error:
Project 'ESP.Console' targets framework '.NETStandard'. The Entity Framework Package Manager Console Tools don't support this framework.
However, the 'ESP.Console' app doesn't target .NETStandard, it's targetting net472:
<PropertyGroup>
<TargetFramework>net472</TargetFramework>
<LangVersion>7.3</LangVersion>
<OutputType>Exe</OutputType>
</PropertyGroup>
I have ESP.Console console app set as my startup project, and I have the ESP.Data project as my default project in the Package Manager console.
This is the setup for ESP.Data.csproj:
<PropertyGroup>
<TargetFrameworks>netstandard2.1;net472</TargetFrameworks>
<EmbeddedResourceUseDependentUponConvention>true</EmbeddedResourceUseDependentUponConvention>
</PropertyGroup>
I need this to target both netstandard and net472 while I am in the process of converting other applications in the solution to run on .net core.
Why am I getting this error? Is there another command like dotnet ef I can use that will work with my EF 6.4 project?
We've used EF migrations on this solution hundreds of times, but since the last time I needed to run a migration we've done two major changes to the solution- converted all the csproj files to use the new format (with PackageReference, etc) and converted the core projects to target either .net standard 2.0 or 2.1 where needed. So I think the issue is related to that.
Attempting to change ESP.Console application to run as netcoreapp3.1 gave the same error.

I have found a solution to my problem, though it is a bit messy since I will need to make a temporary change to a csproj file in order to get this to run.
In my case, the ESP.Data (the project housing my DbContext) was targeting both net472 and netstandard2.1, I altered the Data project to remove the netstandard2.1 target framework. It seems there is a bug in VS that is saying that the StartupProject targets NetStandard instead of saying that the Target project does. After I create the migration, I can add the target back again.
I will be moving to .net core compilation soon, and will therefore need that netstandard 2.1 target at some point, so I'm not sure what I'll do when that comes. I may need to preserve a net472 console application to use in the future and continue targeting net472 in my data project after that migration is done in order to continue to create migrations.

I had a simular problem.
My problem was, that I was targeting netcoreapp3.1 with my startup project and used Entity Framework 6 tools.
When I switched to EntityFrameworkCore tools it worked.

Might be a bug in Visual Studio -- I was seeing this error after I changed the Startup Project to the correct project with my migrations, even though my project uses .NET Framework 4.8.
Tried several things with no luck, but then closing and re-opening Visual Studio fixed the problem.

Downgrading MSbuild file from 4.0 to 3.5

I've got a heap of csproj files that were created with Visual Studio 2010 and targeted .NET 4.0.
I am now trying to compile on Mono 2.6.7 with xbuild, however 2.6.7 can't compile verison 4 msbuild projects. (2.10.1 has no issues, which is what we've been using, but I want to do an experiment on 2.6.7).
Using MonoDevelop I've changed the Runtime Version to Mono / .NET 3.5, and it compiles fine under 2.6.7. Changing to use xbuild however fails.
What steps are required to change the MSBuild version to 3.5? The top line in the csproj file is pretty obvious:
<Project ToolsVersion="4.0"
And changing that is easy, but I'm concerned there are less obvious things that should also be changed.
Anyone know the definitive way to downgrade from a 4.0 to 3.5 msbuild file?

I don't know of an authoritative guide, but having done this several times I can say what I know.
For a simple Class Library or WinForms application, it's pretty straight forward:
The ToolsVersion on the project file needs to be set to 3.5, as you indicated.
If there is an OldToolsVersion element (meaning it was previously upgraded) in the project file, it should be removed. The same goes for FileUpgradeFlags and UpgradeBackupLocation elements. Basically, you don't want the OldToolsVersion to be the same as the current version.
If you were using the Client Framework profile, in 3.5 the element is called TargetFrameworkSubset. In 4.0, it's called TargetFrameworkProfile, so the element should be renamed. (Not sure of the applicability to Mono on this one).

Using MonoDevelop, Project->Export the solution to VS2008 format.

Are you sure you have to downgrade the MSBuild version? Just compile with 2.10, switch your environment to 2.6.7, and run the tests.