`UseStaticFiles` should display the default PhysicalFileProvider default path when using a constructor that doesn't override the default `IFileProvider`

[MaximRouiller]

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

This request is related to a discoverability issue for UseStaticFiles extension. If do not start from a default template and add UseStaticFiles(), the inline xmldoc do not describe the default local physical path it will try to fetch the static files from.

• Running dotnet run does not log the issue in the console that no path /wwwroot exist in the project and that UseStaticFiles will do nothing.
• Creating a static file at the root and trying to match the url and the physical path only returns a 404 without any more help.

Describe the solution you'd like

Default values like /wwwroot for static files should be document in the xmldoc of the API at the point of calling as to help people avoid having to switch context between their code and the docs.

Additionally, calling the extension UseStaticFiles while the default physical path /wwwroot doesn't exist should create an warning message in the logs to warn the developer of a misconfiguration. If implemented, this message should only be shown once as to avoid polluting the logs.

Additional context

My context here is for new adopter of .NET that are simply trying to create a simple API. It should be easy for them to create code without relying on the docs unless they are stuck.

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[MaximRouiller]

Is that something that the .NET team would accept a PR for?

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.