Open DanielHabenicht opened 10 months ago
Not using Visual Studio myself (not reproducing in Rider). If anyone have an idea on possible workarounds on our end, please let us know here.
Visual Studio requires the build tasks to target net472
Visual Studio requires the build tasks to target net472
That's unfortunate. Are there any tracking issues for VS to support modern .NET?
I guess to quote from this page,
- Full MSBuild: This version of MSBuild usually lives inside Visual Studio. Runs on .NET Framework. Visual Studio uses this when you execute Build on your solution or project. This version is also available from a command-line environment, such as the Visual Studio Developer Command Prompt, or PowerShell.
- .NET MSBuild: This version of MSBuild is bundled in the .NET Core Command Line. It runs on .NET Core. Visual Studio doesn't directly invoke this version of MSBuild. It only supports projects that build using Microsoft.NET.Sdk.
It doesn't look like it's going to change anytime soon.
I've explored downgrading everything to .NET Standard 2.0 and while there are shims for most stuff, I wasn't able to find one for https://learn.microsoft.com/en-us/dotnet/api/system.reflection.nullabilityinfo, which is required for detecting nullable/optional parameters. Also we are using reflection extensively on build, so there could be other issues due to TF mismatch, even if everything would compile.
Overall, I think it'd make more sense to figure a workaround for VS users instead of downgrading target framework. For example, maybe we can somehow detect VS or .NET version in the build script and invoke dotnet publish
via <Exec ...
. If someone happen to make this work (or have other ideas), please share/send a PR.
Thats ok, we are also just working around it by using the dotnet commands.
The main logic of the app is in a different project anyhow, so VS developers can just disable the Bootsharp based project and switch to commandline if they need to.
The goal of opening this issue (from my mind) was just to highlight the problem, and maybe find a workaround. I also think that working on backwards compatibility is not worth it if its that big of a task.
One solution I have adopted for my project earlier is to target both net8.0 and also net472, and package the binaries of the libraries that don't exist in the net472 runtime into the nuget package. It's not complicated but it just takes a bit of time to test and make sure it works.
Just hope that maybe somebody else came across the same error:
dotnet build
is running just fine. Only VS gives problems.