-
Notifications
You must be signed in to change notification settings - Fork 5.9k
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 cli Project Tools - prefercliruntime #7292
Comments
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 |
Is this going anywhere? |
Another quarter. Ping! @livarcocc @KathleenDollard |
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? |
@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. |
@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. |
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. |
I'm pretty sure it's supposed to be just root instead of "lib" folder: (it's a master branch at the time of writing) |
Similar search under Duck about the third result, behind dognet-nuget-locals and global-tools funnily enough, |
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. |
@wli3 Does the runtime roll forward functionality make prefercliruntime obsolete, or are there still scenarios that require it? |
roll forward functionality applies to dotnet tools, prefercliruntime applies to project tools. And dotnet tools is a replacement for project tools. |
Closing this issue, since project tools are replaced by dotnet tools and prefercliruntime isn't relevant to dotnet tools. |
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:
The text was updated successfully, but these errors were encountered: