dotnet cli Project Tools - prefercliruntime

[amis92]

There is no documentation for the file prefercliruntime which affects DotNet CLI Project Tools.

I've tried searching for it on the docs webpage: https://docs.microsoft.com/en-us/search/index?search=prefercliruntime

There's no results there, neither are there any in this repo.

I believe it should be a part of this sub-topic: https://docs.microsoft.com/en-us/dotnet/core/tools/extensibility#building-tools

This is currently the most official resource/sample: https://github.com/dotnet/cli/tree/rel/1.0.0/TestAssets/TestPackages/dotnet-prefercliruntime

This topic is also referenced in some depth in these issues:

• https://github.com/dotnet/cli/issues/4764
• Can't restore a DotNetCliToolReference for a tools package that targets netcoreapp1.1 NuGet/Home#4396

[mairaw]

Thanks for letting me know about this @amis92. Somehow I missed the tag last year and no one ever brought the need for docs for that before.

@livarcocc @KathleenDollard we’ll need more info about this and what’s the current state of tools

[amis92]

Is this going anywhere?

[amis92]

Another quarter. Ping! @livarcocc @KathleenDollard

[mwpowellhtx]

Whether a "file exists" to signal the CLI seems like a bit of a hack to me? I mean, not even a JSON configuration, for instance?

[amis92]

@mwpowellhtx since the project tools are getting deprecated in favor of Local Tools, I don't think this'll ever get any traction. And Local Tools don't have a problem like that anyway.

[mwpowellhtx]

@amis92 Well, that's really the bottom line. That, or what's the migration path. What is Local Tools, are there links for that? Thanks.

[amis92]

http://lmgtfy.com/?q=dotnet+local+tools

First result:
https://github.com/dotnet/cli/issues/10288

[KathleenDollard]

Here is text that @wli3 put together:

It is an empty file under the root of “lib” folder of the nupkg with name “prefercliruntime” (case sensitive on Linux). The existence of it indicates the tool prefer to use dotnet SDK’s runtime(to original bundled SDK’s runtime) instead of the runtime it built with (stored in MYTOOL.runtimeconfig.json). However, if SDK’s runtime version is different in major version of runtimeconfig.json’s version. It will be no longer be honored.

[amis92]

I'm pretty sure it's supposed to be just root instead of "lib" folder:

https://github.com/dotnet/cli/blob/24d003f0e06130c951b3594c5a2e7ee06d50a31c/TestAssets/TestPackages/dotnet-prefercliruntime/dotnet-prefercliruntime.csproj

(it's a master branch at the time of writing)

[mwpowellhtx]

Similar search under Duck about the third result, behind dognet-nuget-locals and global-tools funnily enough, ?q=dotnet%2Blocal%2Btools&ia=web. Thanks... 👍

[wli3]

Sorry, I misread the test here

It should be under the root.

It is an empty file under the root of the nupkg with name “prefercliruntime” (case sensitive on Linux). The existence of it indicates the tool prefer to use dotnet SDK’s runtime(to original bundled SDK’s runtime) instead of the runtime it built with (stored in MYTOOL.runtimeconfig.json). However, if SDK’s runtime version is different in major version of runtimeconfig.json’s version. It will be no longer be honored.

[tdykstra]

@wli3 Does the runtime roll forward functionality make prefercliruntime obsolete, or are there still scenarios that require it?

[wli3]

roll forward functionality applies to dotnet tools, prefercliruntime applies to project tools. And dotnet tools is a replacement for project tools.

[tdykstra]

Closing this issue, since project tools are replaced by dotnet tools and prefercliruntime isn't relevant to dotnet tools.