buildMultiTargeting is not used anymore for NuGet packages
- Dominant language
- C#
- Stars
- 5.5k
- Forks
- 1.5k
- Avg merge
- 1d 8h
- Merged PRs (30d)
- 141
Description
### Issue Description
When building a project that targets .NET Core 3.1 and .NET 5.0 and a NuGet package is created, it always uses the package version 1.0.0. Other versions set by the build process are ignored. It works when targeting only .NET Core 3.1.
### Steps to Reproduce
1. Create a new project and target .NET Core 3.1 and 5.0
2. Add it to a Git repository and set a version tag like `v2.0.0`
3. Install the NuGet package [Unclassified.NetRevisionTask](https://github.com/ygoe/NetRevisionTask)
4. Build the solution and see the package file name
### Expected Behavior
The package file name should contain the version 2.0.0 from the Git tag. This is what happened in the past. I'm not using multi targeting often so I cannot say how many years it was ago that it worked.
### Actual Behavior
The `Version` property set by the build process of NetRevisionTask is ignored and the package is always named 1.0.0.
### Versions & Configurations
Visual Studio 2019 16.8.4 on Windows 10. Happens when building from VS and from the dotnet CLI.
Running with more detailed output doesn't give useful information. `-v:normal` shows me the expected version detection but then claims that the package is up to date, even if I just deleted the while bin directory. `-v:d` buries me under tons of stuff (~5000 output lines).
I can imagine that you believe that's an issue with my build tool, but I'm not an msbuild expert and this did work in the past, now it doesn't anymore. I have to assume that something was changed in the msbuild API that needs to be updated in tools that use it. I just can't find any information about that. I certainly never tried it with .NET 5 before, but it worked with older versions like .NET Core 2.0 and 2.2.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.