Consider setting `EnableDefaultEmbeddedResourceItems` to `false` by default for file-based apps

[jjonescz]

To help mitigate issues like

• Attempting to Run WinForms Application Using dotnet run fails #51494
• MSB3552: Resource file "**/*.resx" cannot be found when there is a long path msbuild#12546
• dotnet run file.cs should not pick up implicit build files by default #49826

I think people don't expect a simple file-based app to include ./**/*.resx files. When their file-based app becomes more complex, it would be more acceptable to start including default items. For example, if one adds #:sdk Microsoft.NET.Sdk.Web it will include ./**/*.json files and that seems fine.

This might be considered a breaking change. Although not a very big one, since for simple file-based apps, if the CSC-only optimization kicks in, default items like ./**/*.resx are not considered anyway (see #50912).

dotnet project convert would not need to include this property in the generated project, it's enough if it doesn't copy the .resx files to the output directory (which should simply just work thanks to the logic to find default items via msbuild during the conversion).

This change could also help with perf: #50912 - when we fix that issue, we wouldn't need to glob for ./**/*.resx on every run just to check that inputs are up to date.

Open questions

• Should EnableDefaultEmbeddedResourceItems become true when the file-based app becomes more "complex", e.g., includes an #:sdk directive? Or should it remain false by default for all file-based apps, and people would need to opt-in via #:property EnableDefaultEmbeddedResourceItems=true?
• Should there be a feature gate (like LangVersion, TFM) for changes like this?
• Should we have EnableDefaultNoneItems=false, too? These seem to be useful only for being displayed in Solution Explorer (which isn't applicable to file-based apps anyway) or copy to output directory (but that needs some customization of build anyway so if ./**/* is not included by default, one would just use <None Include/> instead of <None Update/>).

@dotnet/run-file @rainersigwald for thoughts

[333fred]

I like it. I think that strikes a pragmatic balance between "I just want to write a quick script" and "I want to do something actually complicated".

[DamianEdwards]

I think this is a reasonable compromise, i.e. setting it to false unless a specific SDK other than the default is opted in to. Would we take this in servicing, aka 10.0.101?

[jjonescz]

Would we take this in servicing, aka 10.0.101?

It doesn't feel like it would meet the bar to me

[DamianEdwards]

It doesn't feel like it would meet the bar to me

It's tricky as changing any default like this will be breaking but at the same time this feature is brand new and we had to make design choices with very little feedback. Taking it in 10.0.200 would still be beneficial but arguably taking it servicing would actually be less impacting given how quickly after GA it would be.

[baronfel]

I'd go ahead and get the PR going targeting 200, then bar-check with Tactics. Damian's point is persuasive to me and if the blast radius is kept to File Based Apps there's a better chance of getting approval.