`dotnet run file.cs` should not pick up implicit build files by default

[333fred]

Today, dotnet run file.cs picks up implicit build files from the surrounding environment. This means that anywhere in the context of an existing .NET repo, I cannot make a simple script to perform a refactoring or automate build processes without the Directory.Build.props/targets/packages for that repo getting pulled in automatically, which is usually undesirable in these types of scripts. #49808 allows working around this by using --file; while this will be needed for running .cs files in the same directory as a .csproj file for backcompat, it should not be necessary to pass --file when in a directory that does not have a project file in it. Consider, for example, replacing https://github.com/dotnet/roslyn/blob/main/eng/generate-compiler-code.ps1 with a .cs script. dotnet run file.cs in this directory could never have succeeded before the new feature, as there is no project in this directory. Yet, dotnet run file.cs also doesn't work in 10p5 or p6, because the implicit project files from this directory and parent directories are picked up.

Practically speaking, I expect most of my usage of dotnet run file.cs to be in 3 types of scenarios:

1. Confirming behavior of snippets of C# code. These types of things can be thrown in a clean directory in /tmp and are unaffected by this issue.
2. Temporary scripts to do refactorings/reorganizations of code, files, or other similar scenarios. I expect most of these to happen inside repositories that are already .NET repositories, so picking up implicit build files is going to negatively impact my ability to use them here.
3. Replacing build scripts with .cs files; these also should not pick up on the implicit build files in my directory. They automate the rest of the build process, they don't need to pull in the nuget packages the actual app depends on and such.

Related to #49790.

[jjonescz]

allows working around this by using --file; while this will be needed for running .cs files in the same directory as a .csproj file for backcompat, it should not be necessary to pass --file when in a directory that does not have a project file in it.

--file would still pick up any implicit build files like Directory.Build.props in the directory tree of the script. --file only doesn't pick up project files in the current directory like MyProject.csproj.

dotnet run file.cs in this directory could never have succeeded before the new feature, as there is no project in this directory.

I don't understand this. If there is no project, that's the ideal scenario - dotnet run file.cs should always have built the file! If there was a project, dotnet run file.cs would fall back to running the project. Implicit build files like Directory.Build.props are unrelated to this behavior.

[333fred]

I don't understand this. If there is no project, that's the ideal scenario - dotnet run file.cs should always have built the file! If there was a project, dotnet run file.cs would fall back to running the project. Implicit build files like Directory.Build.props are unrelated to this behavior.

Try it yourself. Dir.Build.props/targets/packages are breaking this scenario.

[jjonescz]

Try it yourself. Dir.Build.props/targets/packages are breaking this scenario.

Sorry I meant I don't think --file would have any effect on that. Otherwise I agree that it's broken :)

[RikkiGibson]

It would be useful to know what exactly is broken when Dir.Build.Props etc is picked up, for eng/app.cs in Roslyn repo, for example.

The suggestion is to just default to these implicit build files not being included right? If the user wants they can specify a property or something to bring them back in?

[jjonescz]

It would be useful to know what exactly is broken when Dir.Build.Props etc is picked up, for eng/app.cs in Roslyn repo, for example.

In Roslyn repo, "static graph restore" is picked up from Dir.Build.props, and that doesn't currently work with file-based apps. We should fix that anyway. You can work around that by setting #:property RestoreUseStaticGraphEvaluation=false.

Next, all .xlf files are picked up from artifacts/ folder and processed by some arcade targets. That takes a very long time and eventually fails because the files don't have unique file names. #49863 should fix that for standard artifacts (but not arcade artifacts, I have a fix prepared for that as well though). Note that this only happens for scripts in the roslyn root folder, not in eng/ for example where artifacts/ is not visible.

Next, all .resx files are picked up from project directories src/. Again arcade targets require the files to have unique names so this fails. Can be worked around by setting #:property EnableDefaultEmbeddedResourceItems=false. Again not an issue for scripts in a subfolder.

The suggestion is to just default to these implicit build files not being included right? If the user wants they can specify a property or something to bring them back in?

In that case we would ideally also exclude all default items (like .resx, .json) that we currently include. And project convert command probably could not preserve this behavior while maintaining a clean project file (because excluding Dir.Build.props needs to be done before importing Sdk.props, so we need explicit <Import> elements).

[bgrainger]

This means that anywhere in the context of an existing .NET repo, I cannot make a simple script to perform a refactoring or automate build processes without the Directory.Build.props/targets/packages for that repo getting pulled in automatically, which is usually undesirable in these types of scripts.

This relates to a comment I left on #49192:

To some extent, it feels odd that the implicit csproj does even inherit the Directory.Packages.props settings from a parent directory of the *.cs file being run. (I can see the arguments for and against, but it does raise some questions of how "self-contained" these single-file C# scripts should be. If I were to copy Build.cs from the "Floating #:package Version" example above to a different folder, say C:\Temp, it would "just work".)