New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dotnet restore's "-r" parameter should set RuntimeIdentifier instead of RuntimeIdentifiers if only one is specified #9518
Comments
From @livarcocc on June 19, 2018 15:17 @dsplaisted to comment and close. |
Here's the documentation of this behavior: https://docs.microsoft.com/en-us/dotnet/core/deploying/runtime-patch-selection @livarcocc @nguerrera Should we consider setting the |
Also @KathleenDollard for discussion on whether we should change the behavior of the |
From @dasMulli on June 19, 2018 17:17 Maybe it would help if NuGet actually re-evaluated the project file for each RID, since putting <RuntimeIdentifiers>osx-x64;win-x64</RuntimeIdentifiers> no longer helps to fetch all RID-specific packages in advance (in fact, it will even go ahead and download old versions that |
@dasMulli When we were designing the runtime roll-forward for 2.1.300, we considered having separate restores for each RID. We may do so eventually but it would be a significant amount of work. The design we were thinking of was that there would be a separate assets file per combination of Configuration, TargetFramework, and RuntimeIdentifier. Note that if you want to do self-contained publish for different RIDs, you can set the |
-r
parameter should set RuntimeIdentifier
instead of RuntimeIdentifiers
if only one is specified
-r
parameter should set RuntimeIdentifier
instead of RuntimeIdentifiers
if only one is specified
Technically, the single assets file has separate entries for distinct RIDs (since they have their own graphs). So it would be possible for NuGet to evaluate the project for each RID. I think there was even a NuGet bug tracking that possibility at one point, though I am not finding it now. My concern with that is perf of evaluating N times. True that you won't get no-op if you're changing RIDs, but I think even no-op would have to do N evaluations with the multiple evaluation approach. |
@richlander Do you see any downside in storing the RID in It is a functional change, but it fixes a regression. We are considering this for 2.2.1xx |
@eerhardt @natemcmaster Do you remember whether there was a specific reason that the |
It's been like that since that option was added: dotnet/cli#5079. I'm not sure it was considered to switch based on how many were specified. |
So I think it is a good change, but there is a potential break to |
Is this still an issue since it doesn't look like this issue is targetting the 2.1 or 2.2 milestone any longer and according to ASP.NET Core 2.2 to 3.0 migration guide Microsoft.AspNetCore.App is now removed from csproj? |
From @mikeharder on June 19, 2018 2:11
Repro Steps
dotnet new console --no-restore
dotnet restore -r win-x64
dotnet build -r win-x64 --no-restore
These steps work as expected in CLI 2.1.300. However, in CLI 2.1.301 the build step fails:
The error message is misleading, since the
RuntimeIdentifier (-r)
is set during both restore and build.A workaround is to remove the
--no-restore
from thedotnet build
command:Is this a bug or by design? Is it expected that
dotnet build -r runtime --no-restore
should always work afterdotnet restore -r runtime
?CC: @JunTaoLuo
Copied from original issue: #2344
The text was updated successfully, but these errors were encountered: