Consider not excluding `.well-known/*` from publishing

[tiesmaster]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

I'm trying to add a security.txt to our site, as a best practice. It's added as wwwroot/.well-known/security.txt, and it's showing up on dotnet run. However, when the app gets deployed, the file doesn't get served. After debugging, it appears that the file doesn't get published (the pipeline does a "plain dotnet publish on a linux host). I suspect it's because .well-known is a "dot file", and therefore gets ignored.

This appears to be a known issue, and the suggested answer fixes the problem, and the file gets published.

Describe the solution you'd like

I suggest that the folder .well-known should be treated differently, and not excluded from publishing, as it's purpose is to serve "well known" content, defined by the RFC 5785.

Additional context

No response

[baronfel]

I think this is completely reasonable, but would be something that's more directly applicable to the Web SDK rather than the base set of default includes. @DamianEdwards what do you think?

[DamianEdwards]

Yep agreed, makes sense to have the web SDK support this. @vijayrkn could we get this added?

[vijayrkn]

Looked at this and the update needs to happen in the Razorsdk where these globs are defined.

The line in the Razor SDK that excludes this file from under wwwroot:
https://github.com/dotnet/sdk/blob/d064f1fd94d4cebfb81e21b85fffe0697e3be76c/src/RazorSdk/Sdk/Sdk.Razor.StaticAssets.ProjectSystem.props#L30

The property DefaultExcludesInProjectFolder is the one that excludes all dot folders.
https://github.com/dotnet/sdk/blob/3b684c6ff1464a1b5fa026542e096f74f2ed33a0/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.DefaultItems.targets#L41

Since the updated behavior needs to be both in tooling & published assets, it is best to update this in the Razor SDK itself rather than override it from the websdk.

@mkArtakMSFT - Since you manage the RazorSDK, can someone from your team pick this up? Should be a straightforward change.