dotnet restore should have an option for the runtimes to restore

[eerhardt]

Currently dotnet restore supports two modes for restoring runtime assets.

1. Explicitly putting the runtimes in the "runtimes" section of the project.json
2. --infer-runtimes, which is a temporary

If you don't have a "runtimes" section in your project.json, dotnet restore will do a "RID-less" restore, which means that it is impossible to publish your app as a stand-alone (i.e. not portable) .NET Core app. Publishing a stand-alone app needs to have a runtime restored.

However, if you call dotnet restore --infer-runtimes, it will infer too many runtimes. For example, on a Windows x64 machine, it will infer both x64 and x86. This is broken because:

1. The x86 assets might not be around (because they get built by the x86 build, not the x64 build)
   • This is also a reason not to put the runtimes in the project.json file - the assets from all the other runtimes might not be around yet.
2. I may not be producing x86 assets at all!

To solve these problems, I propose we add a new option to dotnet restore: -r --runtimes that takes a list of RIDs to restore. Going one step further, there can be a "use the current RID" (and only the current RID), so I don't need to find what the current RID is. I just call dotnet restore --runtimes current and it does a restore for "win7-x64" if I'm on windows x64, "rhel.7-x64" if I'm on Red Hat, etc.

[eerhardt]

/cc @piotrpMSFT @brthor @anurse @emgarten

[analogrelay]

This is by design, we had --runtime and removed it because it meant that the command line args could dramatically change the outputted lock file, which wasn't obvious to users. It was deemed desirable to have all the runtimes listed in the project.json in order to make that clearer. /cc @DamianEdwards @davidfowl

I would be in favor of reviving --runtime as a way to select from the RIDs in the project.json and limit the restore to only those RIDs, so that in scenarios where your project supports multiple RIDs but aren't cross-publishing, you don't pull down extra stuff. But it wouldn't be able to add new RIDs.

[TheRealPiotrP]

@anurse that seems reasonable. It would return consistency with other dotnet commands wherein we "do everything" by default and allow folks to trim down by --runtime and --framework

[TheRealPiotrP]

By the way, the lack of this trim-down functionality is causing serious issues for CLI. During x64 builds we don't have access to x86 packages and thus are unable to do a local package restore of the NetCoreApp metapackage. Could this issue get fixed soon so we don't go too far down the path of workarounds?

[yishaigalatzer]

@piotrpMSFT I would fix your build, rather than force this issue through right now. You should have access to all packages on the feeds.

[eerhardt]

You should have access to all packages on the feeds.

This is not the case. The packages are getting built during the same build that is consuming them.

I would fix your build

The issue isn't dotnet/cli's build. The issue is any repo that tries building native and managed assets.

The CLI isn’t a special case. There can and will be plenty other teams/repos/etc that will be building native and managed code together. We do it in CoreFX and CoreCLR too. I can imagine many of our customers will have native libraries that they want to build in harmony with their managed code/apps.

When doing a full build of a repo, it needs to build the native assets, which are architecture specific. After the native assets, other projects are going to consume the "runtime" packages built during the native part of the build. However, the way --infer-runtimes works is that it requires both x86 and x64 runtime packages to already exist. But that isn't the case. Since this was the x64 build, it only made x64 runtime packages. (Or what if my app doesn't even want to produce x86 packages? It is strictly x64.)

Putting the RIDs in the project.json file (and having to restore all RIDs at the same time) makes it even worse. How can I build osx, ubuntu and windows native assemblies during my single build on a single machine?

The ask is to have a way to tell dotnet restore to only restore for a specific RID, in our case the current RID. That way it doesn't go looking for packages that are being created by other builds and aren't available yet.

[jkotas]

Does this mean that I have to list all supported runtimes in my project.json even if I have portable code that will run on any runtime that supports the given netstandard? If it is the case, it looks pretty broken to me.

[yishaigalatzer]

I do agree here

[dagood]

This might be crazy, but it seems to me like dotnet publish might actually be where runtimes should be found/restored. This issue seems similar to the PCL profile problem, where if a new framework comes along you need to edit the project definition to add it. I'm wondering if maybe you should be able to publish a project for a new platform without any project changes. I'm probably oversimplifying a bunch of design decisions that were already made a while ago (and it's definitely intuitive for "restore" to be the only online step), but that's my two cents.

[DamianEdwards]

This is indeed an eventual goal (take a "portable" project and publish for
a specific platform), we just have to do a bunch of design and work to get
to that place. It's very unlikely to happen for v1.0

On Wed, Apr 27, 2016 at 4:07 PM, Davis Goodin notifications@github.com
wrote:

This might be crazy, but it seems to me like dotnet publish might
actually be where runtimes should be found/restored. This issue seems
similar to the PCL profile problem, where if a new framework comes along
you need to edit the project definition to add it. I'm wondering if maybe
you should be able to publish a project for a new platform without any
project changes. I'm probably oversimplifying a bunch of design decisions
that were already made a while ago (and it's definitely intuitive for
"restore" to be the only online step), but that's my two cents.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#2534 (comment)

Cheers,
Damian

[davidfowl]

We need a lock file per runtime instead of listing all targets in a single lock file. That way publish can just run restore for that specific RID

[chadwackerman]

I just hit this today. I have an application that targets .NET 4.61 as well as .NET Core. Today I had to add a nuget.config file because "dotnet restore" on a tiny Linux worker node is pulling down all the Windows binaries, then failed trying to talk to the overloaded MyGet server attempting to pull down a different Windows-only binary that's clearly referenced as a net461-only dependency in project.json.

This was unexpected behavior for a number of reasons but at a minimum I expected to find a dotnet restore -r option that matches the dotnet publish -r option.

As an aside "dotnet restore" appears to have a hardcoded 60 second timeout for package retrieval. Not sure when that would be optimal or desirable.