Specifying both -f ... and -r ... to dotnet build fails to restore if multiple frameworks are present in the project file #11653
Comments
|
The gist is that NuGet respects both TargetFramework and TargetFrameworks, but in some scenarios, people want to build only for a specific TargetFramework, and NuGet simply wouldn't even look at TargetFramework because TargetFrameworks is set. 2 options:
There are a few trade-offs with either approach. The first one is a more general solution, but it also has the potential to break more things. |
|
After talking to @dsplaisted, sounds like they want this to be fixed in the next minor release, 6.0.300. |
nkolev92
added
Type:DCR
|
In the new issues, we'll discuss it during our next triage meeting Thursday. |
|
@nkolev92 Any update on this? Will this make it into 17.2? |
|
We didn't get to it unfortunately. I think 17.2 is not likely to happen as this is something that would have ideally been scheduled at the beginning of the sprint if it were to make into 17.2. |
|
Just adding onto #11653 (comment), both approaches are functionally equivalent for the The first approach allows |
|
@jonathanpeppers & @rolfbjarne would the options above meet your CLI requirements in dotnet/sdk#21877 (comment)? |
|
I've never seen anyone do |
|
I agree |
|
VS doesn't really run msbuild restore, it runs it's own. So when you run F5, you're only building for one framework, but restore is still running for all of them, so the equivalent problem shouldn't exist there. |
nkolev92
added
the
Priority:1
|
Whatever we decide to do, the following target would need to be updated to respect is as well: <Target Name="_ValidateRuntimeIdentifier"
Condition="'$(RuntimeIdentifier)' != '' And '$(_RuntimeIdentifierValidation)' != 'false'"
BeforeTargets="Restore;Build;ResolvedFrameworkReference;ResolveRuntimePackAssets;ProcessFrameworkReferences">
<PropertyGroup>
<_IsValidRuntimeIdentifier Condition="@(_XamarinValidRuntimeIdentifier->WithMetadataValue('Platform', '$(_PlatformName)')->WithMetadataValue('Filename', '$(RuntimeIdentifier)')->Count()) > 0">true</_IsValidRuntimeIdentifier>
</PropertyGroup>
<Error Condition="'$(_IsValidRuntimeIdentifier)' != 'true'" Text="The RuntimeIdentifier '$(RuntimeIdentifier)' is invalid." />
</Target>It's coming from It would need the exact same logic that we add in NuGet/SDK. |
That would be me. |
|
I have something that seems to work, cleaning it up now. |
Validating that projects are only restored using valid runtime identifiers have turned out to be an interesting rabbit hole. Nobody seems to dispute the fact that it's a correct validation, the problem is that it apparently turns out quite complicated to not do the wrong thing for projects with multiple target frameworks. In some scenarios apparently the Restore target might want to restore all target frameworks, which breaks down if whatever the user wants to do requires setting a runtime identifier, because then that runtime identifier is set for all target frameworks. So for the sake of simplicity, we're going to try removing this validation for the Restore target (we're keeping it for the Build target). There are thus two potential scenarios: 1. The Restore succeeds using invalid runtime identifiers. This shouldn't affect valid builds (since those should be completely separate due to using different runtime identifiers). 2. Something else breaks. At worst the user will be given a less comprehensible error message. Time will tell if this is better or worse than the current experience. Ref: NuGet/Home#11653 Ref: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1558247
Validating that projects are only restored using valid runtime identifiers have turned out to be an interesting rabbit hole. Nobody seems to dispute the fact that it's a correct validation, the problem is that it apparently turns out quite complicated to not do the wrong thing for projects with multiple target frameworks. In some scenarios apparently the Restore target might want to restore all target frameworks, which breaks down if whatever the user wants to do requires setting a runtime identifier, because then that runtime identifier is set for all target frameworks. So for the sake of simplicity, we're going to try removing this validation for the Restore target (we're keeping it for the Build target). There are thus two potential scenarios: 1. The Restore succeeds using invalid runtime identifiers. This shouldn't affect valid builds (since those should be completely separate due to using different runtime identifiers). 2. Something else breaks. At worst the user will be given a less comprehensible error message. Time will tell if this is better or worse than the current experience. Ref: NuGet/Home#11653 Ref: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1558247
Validating that projects are only restored using valid runtime identifiers have turned out to be an interesting rabbit hole. Nobody seems to dispute the fact that it's a correct validation, the problem is that it apparently turns out quite complicated to not do the wrong thing for projects with multiple target frameworks. In some scenarios apparently the Restore target might want to restore all target frameworks, which breaks down if whatever the user wants to do requires setting a runtime identifier, because then that runtime identifier is set for all target frameworks. So for the sake of simplicity, we're going to try removing this validation for the Restore target (we're keeping it for the Build target). There are thus two potential scenarios: 1. The Restore succeeds using invalid runtime identifiers. This shouldn't affect valid builds (since those should be completely separate due to using different runtime identifiers). 2. Something else breaks. At worst the user will be given a less comprehensible error message. Time will tell if this is better or worse than the current experience. Ref: NuGet/Home#11653 Ref: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1558247
…tore. (#15491) Validating that projects are only restored using valid runtime identifiers have turned out to be an interesting rabbit hole. Nobody seems to dispute the fact that it's a correct validation, the problem is that it apparently turns out quite complicated to not do the wrong thing for projects with multiple target frameworks. In some scenarios apparently the Restore target might want to restore all target frameworks, which breaks down if whatever the user wants to do requires setting a runtime identifier, because then that runtime identifier is set for all target frameworks. So for the sake of simplicity, we're going to try removing this validation for the Restore target (we're keeping it for the Build target). There are thus two potential scenarios: 1. The Restore succeeds using invalid runtime identifiers. This shouldn't affect valid builds (since those should be completely separate due to using different runtime identifiers). 2. Something else breaks. At worst the user will be given a less comprehensible error message. Time will tell if this is better or worse than the current experience. Ref: NuGet/Home#11653 Ref: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1558247 Backport of #15357 Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
…tore. (#15490) Validating that projects are only restored using valid runtime identifiers have turned out to be an interesting rabbit hole. Nobody seems to dispute the fact that it's a correct validation, the problem is that it apparently turns out quite complicated to not do the wrong thing for projects with multiple target frameworks. In some scenarios apparently the Restore target might want to restore all target frameworks, which breaks down if whatever the user wants to do requires setting a runtime identifier, because then that runtime identifier is set for all target frameworks. So for the sake of simplicity, we're going to try removing this validation for the Restore target (we're keeping it for the Build target). There are thus two potential scenarios: 1. The Restore succeeds using invalid runtime identifiers. This shouldn't affect valid builds (since those should be completely separate due to using different runtime identifiers). 2. Something else breaks. At worst the user will be given a less comprehensible error message. Time will tell if this is better or worse than the current experience. Ref: NuGet/Home#11653 Ref: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1558247 Backport of #15357 Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Original bug: dotnet/sdk#21877
Repro:
The problem is that it's trying to restore the
net6.0-maccatalystframework from the project file using theios-arm64RuntimeIdentifier, which fails, becauseios-arm64is not a valid RuntimeIdentifier for Mac Catalyst.It seems that the implicit restore by "dotnet build" does not take into account the specified -f value (or takes into account the -r value when it shouldn't).
Binlog: msbuild.binlog.zip
Further technical details
dotnet --info
The text was updated successfully, but these errors were encountered: