search

dotnet / msbuild

The Microsoft Build Engine (MSBuild) is the build platform for .NET and Visual Studio.
https://docs.microsoft.com/visualstudio/msbuild/msbuild
MIT License
5.23k stars 1.35k forks source link

Update MSBuild's TargetFramework to net5.0 #5678

Closed rainersigwald closed 3 years ago

SabotageAndi commented 4 years ago

What would this mean for MSBuild Tasks? Currently, we are targeting .NET Core 2.1 for them. Do we have to change that to .NET Core 3.1? What happens if a user updates MSBuild/VS and builds a project which has still the .NET Core 2.1 MSBuild task referenced?

rainersigwald commented 4 years ago

@SabotageAndi It shouldn't mean anything for tasks, unless you hit one of the rare breaking change in API surface. MSBuild as part of the .NET SDK is already running on the .NET 5 (or .NET Core 3.1) runtime; this just formalizes that at our layer, enabling us (and task authors) to use new functionality.

SabotageAndi commented 4 years ago

Thanks, @rainersigwald for this quick clarification.

marcpopMSFT commented 4 years ago

Adding a note that we should probably update to net5.0 instead since that will be available shortly. For custom tasks, I would generally recommend that tasks compile against a higher target framework when possible to reduce the rollforward distance but as Rainer pointed out, the risk we have found is low as the runtime generally has enough back compat to cover all MSBuild task likely scenarios.

japj commented 4 years ago

Just to clarify: will the MSBuild in visual studio still run on net framework?

dasMulli commented 4 years ago

I would generally recommend that tasks compile against a higher target framework when possible

From previous experience this is driven by: What is the minimum version that a tool can use MSBuild NuGet pacakges to load a project and execute builds? Either with MSBuildLocator and MSBuild APIs driectly, Roslyn's MSBuildWorkspace or tools like Buildalyzer.

So for third party tools/tasks it's probably easier if the TFMs supported by MSBuild APIs increases every now and then to reduce complexity of MSBuild version / runtime version compatibility tests.

rainersigwald commented 4 years ago

will the MSBuild in visual studio still run on net framework?

@japj Yes, that's not changing here and will continue to target net472.

So for third party tools/tasks it's probably easier if the TFMs supported by MSBuild APIs increases every now and then to reduce complexity of MSBuild version / runtime version compatibility tests.

@dasMulli this is a good point and I think it should be our policy going forward.

benvillalobos commented 3 years ago

Work for this is being done in the arcade update PR. Assigning to myself

rainersigwald commented 3 years ago

As part of this we need to consider what we do with the ref assemblies:

https://github.com/dotnet/msbuild/blob/1ff34e830630ff7c4b6cb008e85ece4f263ace52/src/Directory.Build.targets#L80-L82

With .NET 5.0+, they won't really be netstandard any more, and I think we should consider making them explicitly .NET 5.0 (and then seeing the explicit public-API-breaking changes when we move to 6.0 and so on).