Targeting fixes #470
Targeting fixes #470
Conversation
Without this change, the following scenario fails: - csharp_library rule targets net8.0 + depends on 3rd-party package - 3rd-party package has targets ["net9.0", "netstandard2.0"] In this case, MSBuild will fall back to netstandard2.0. This change replicates that behavior.
dotnet.targeting_packs.bzl contains a nuget_repo declaration for the different targeting packs available on different .NET versions. However, when generating the repo, the latter versions would silently override the former versions' targeting_pack_overrides and framework_list, and thus older versions like microsoft.aspnetcore.app.ref.v8.0.11 would have targeting_pack_overrides containing version 9.0.0 and such. This change ensures that different packages within the same repo do not clobber each other's parameters.
|
Do you have an example of what you are exactly fixing with this? |
|
For the first commit, an example has been given in the commit message: Our projects are targeting net8.0 at the moment, but many packages have upgraded to only support net9.0, and those packages need to fall back to netstandard2.0. Otherwise we'd have to manually pin everything in For the second commit, we have If you'd like I can try to prepare an example project (and hopefully not disappear this time 😅). |
|
If we could add a test that guards us from a regression then that would be awesome. |
|
I'll try to do that later today. |
|
Sorry for the delay, here are the tests. |
sin-ack
force-pushed
the
targeting-fixes
branch
2 times, most recently
from
cca6b49 to
d949aa1
Compare
sin-ack
force-pushed
the
targeting-fixes
branch
from
d949aa1 to
defe0fc
Compare
|
Nice! Thanks a lot for your contribution! |
2 participants
These are a couple fixes for when working with non-latest SDKs such as net8.0. We faced these issues when upgrading from
rules_dotnet0.15.1 to 0.17.5.