dotnet / aspnetcore

ASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.
https://asp.net
MIT License
35.47k stars 10.03k forks source link

Remove copied static files code from WebView project #31078

Open Eilon opened 3 years ago

Eilon commented 3 years ago

As a workaround for another problem we introduced a lot of copied code into the Blazor Desktop WebView package: https://github.com/dotnet/aspnetcore/pull/31071

There's a fair bit of copied code related to static files and content types. The Blazor Desktop packages can't depend on anything in Microsoft.AspNetCore.App because they have to run in places where ASP.NET Core doesn't run, such as Android and iOS.

Options:

  1. Do nothing and keep the copied code (possibly trimming it down to the minimal amount needed, rather than taking entire files)
  2. Move the code to a NuGet package that can be used from everywhere
  3. Something else?
Eilon commented 3 years ago

Ideas:

  1. Delete the copied code that does file extension mapping
  2. Instead, have an MSBuild-time target that computes the MIME types using an MSBuild item group that has all the MIME mappings
    • This would enable users to update/add/remove MIME types if they need something custom
  3. The MSBuild target would store the computed MIME types in some new asset
  4. In the WebViewManager code load the computed MIME types along with the list of embedded files and serve it up

We still need to figure out what to do with copied code for the static file provider that is itself copied, plus the path/query string code that is copied.

ghost commented 3 years ago

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

ghost commented 10 months ago

Thanks for contacting us.

We're moving this issue to the .NET 9 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.