Running file-based apps from $PATH can trip up on global.json in current directory

[omajid]

Is your feature request related to a problem?

I used to write lots of small standalone tools in scripting languages like bash and python. Since file based apps, though, I am trying to start using .NET for the tools.

I created one called ~/bin/collect-npm-packages.cs (~/bin is in my $PATH, meaning I can run this file directly by name). It look like any other script on Linux:

#!/usr/bin/env -S dotnet --

if (args.Length > 0)
...

And I run it as:

$ mkdir ~/test-directory
$ cd ~/test-directory
$ collect-npm-packages.cs .

And it works fine in the brand new directory called test-directory.

Then I tried to run this tool in a checkout of https://github.com/dotnet/aspnetcore/ (branch release/9.0):

$ collect-npm-packages.cs . 
The command could not be loaded, possibly because:
  * You intended to execute a .NET application:
      The application '--' does not exist or is not a managed .dll or .exe.
  * You intended to execute a .NET SDK command:
      A compatible .NET SDK was not found.

Requested SDK version: 9.0.118
global.json file: aspnetcore/global.json

Installed SDKs:
11.0.100-preview.4.26230.115 [/usr/lib64/dotnet/sdk]

Install the [9.0.118] .NET SDK or update [aspnetcore/global.json] to match an installed SDK.

Learn about SDK resolution:
https://aka.ms/dotnet/sdk-not-found

In other words, even though the file based app works fine when invoked directly in another directory, when it sees a global.json, it starts behaving differently. This makes it difficult to use lots of small file-based apps as generic tools.

This is similar to dotnet run should ignore Directory.Build.props and Directory.Build.targets #52804

Describe the solution you'd like

Is there some way to say "opt out of reading global.json"?

Alternatives you've considered

No response

Additional context

No response

[tmds]

cc @jjonescz

[jjonescz]

Seems related to the "isolated" mode - #52804.

But global.json is tricky, because it's read by the native muxer even before control is passed to the dotnet CLI. So either the muxer could add some option to control this (e.g., #!/usr/bin/env -S dotnet --ignore-global-json -- or --sdk-version or --global-json-from or -C) which seems like it would be useful for project-based apps too, or we could add run-file handling to the muxer (make it find global.json in the directory of the entry-point file passed to it).

Alternatively we could add some support for running file-based apps to dnx, that might be simpler to change than the muxer. Also we could make its behavior more suited to shebangs by default and it wouldn't be a breaking change.

cc @dotnet/run-file

[tmds]

But global.json is tricky, because it's read by the native muxer even before control is passed to the dotnet CLI. So either the muxer could add some option to control this (e.g., #!/usr/bin/env -S dotnet --ignore-global-json -- or --sdk-version or --global-json-from or -C)

-S is a GNU extension, it would be preferable to avoid it.

Alternatively we could add some support for running file-based apps to dnx, that might be simpler to change than the muxer. Also we could make its behavior more suited to shebangs by default and it wouldn't be a breaking change.

+1, this was mentioned in #49221 (comment).

Something to think about: should global.json be picked up from the path that the script is on.

[DamianEdwards]

Alternatively we could add some support for running file-based apps to dnx, that might be simpler to change than the muxer. Also we could make its behavior more suited to shebangs by default and it wouldn't be a breaking change.

+1, this was mentioned in #49221 (comment).

Yep see #49495