When restoring DotNetCliToolReferences, choose TargetFramework to restore with based on what the tool package targets

[dsplaisted]

For .NET CLI tools, we want to run the tools on the same version of .NET Core as the tool targets. A tool built for 1.1 should run using the 1.1 shared framework, and a tool built for 2.0 should use the 2.0 shared framework. The tools need to be restored using the same target framework they will run on (otherwise a tool running on 1.1 could end up bringing in 2.0 assets, which would fail).

Currently, the DotnetCliToolTargetFramework property can be set to control what target framework is used when restoring tools. However, different tools in the same project may need to be restored for different target frameworks, and furthermore there's no way for the SDK / CLI to know what version of .NET Core the tools target until the package has been downloaded.

We (@rrelyea, @emgarten, @livarcocc, and @dsplaisted) met to discuss this and came up with the following design:

• The DotnetCliToolTargetFramework will be interpreted by NuGet restore as the maximum target framework that tools can be restored for
• When restoring .NET CLI tools, NuGet will first download the package, and inspect it to see what it targets. It will choose the maximum target framework the package explicitly supports that is less than or equal to the DotnetCliToolTargetFramework. (IE if a tools package has folders for netcoreapp1.0, netcoreapp2.0, and netcoreapp3.0, and the DotnetCliToolTargetFramework is netcoreapp2.1, then it would select netcoreapp2.0.)
• NuGet restore would generate a hash of all the relevant inputs to the tool restore (for example, the DotnetCliToolTargetFramework, the package feeds used, the version of NuGet, etc.)
• NuGet would write the tool's project.assets.json to a folder under .tools which would include the hash, for example .tools\dotnet-mytool\1.0.0-rc\netcoreapp2.0\<hash>.
• NuGet would write a .json file to the intermediate folder which would include the path to the project.assets.json file for the tool (either the full path or the path relative to the packages folder) as well as the target framework used to restore the tool. The CLI and SDK would use this information to find the assets file, create a corresponding .deps.json file, and restore the tool. The path to the .json file for each tool could be something like <BaseIntermediateOutputFolder>\.tools\<toolname>.json.

[emgarten]

We are taking a look at this again now that we have ruled out performing an implicit restore before running tools, but at this point I don't think it will make it in 4.3.

//cc @rrelyea

[matthid]

I just want to let you guys know that this particular issue is really hard to debug if you encounter subtle failures like: fsprojects/FAKE#2097.

Even if this is not implemented an error notifying if "restore framework <> runtime framework" would drastically improve the situation.

[dsplaisted]

@matthid Sorry for the problems you had with dotnet-fake.

We are working on local tools, which will be similar to DotNetCliToolReference tools, but will support the same tool packages as are used for global tools. See here for some more information: https:/dotnet/cli/issues/9782#issuecomment-410033494

As such, we don't expect to fix this issue with DotNetCliToolReference

[matthid]

@dsplaisted That's what I thought. While we have already support 'global tools' via the fake-cli package a lot of people still use dotnet-fake because it is easier to version alongside your other dependencies (especially in the F# community where most use paket).

While from a users perspective I'd urge you to implement a error/warning message for the above situation, I can understand that you don't want to invest any more time in that feature.