search

ligershark / WebOptimizer

A bundler and minifier for ASP.NET Core
Apache License 2.0
753 stars 113 forks source link

Latest release - Breaks bundle due to wrong root path it seems #241

Open jaddie opened 2 years ago

jaddie commented 2 years ago

Not sure why but the latest release breaks the code that previously worked fine for the process, screenshot of code with addition of provider to work around the issue below:

image

BooTeK commented 2 years ago

I suspect the change introduced with pull request https://github.com/ligershark/WebOptimizer/pull/238 might be causing this.

In a project I'm working (netcore3.1) on a call to the method with the signature IFileProvider GetFileProvider(this IAsset asset, IWebHostEnvironment env) returns the last provider of a CompositeFileProvider. In my case it contains a PhysicalFileProvider and a StaticWebAssetsFileProvider in order. The StaticWebAssetsFileProvider is returned as it's the last in the FileProviders list.

Older versions returned the (in my scenario) correct PyhsicalFileProvider. In your case something similar might be happening.

If I interpret the changes correctly it fixed net6.0 support and cache busting but inadvertently broke netcore3.1 in at least a few scenario's. Build 348 seems to be the last version that doesn't contain any changes within the method and doesn't show have the regression.

I'm not sure what the best solution to address this would be but to me it seems always using the last provider within a CompositeFileProvider might be a too naive approach. Should some FileProvider types be excluded within the method (for example a StaticWebAssetFileProvider or are there more types), is expecting a PyhsicalFileProvider a correct assumption?

kham04 commented 1 year ago

Just ran into this. I agree that the .Last() on the FileProviders seems a bit arbitrary. This needs an OfType filter to ensure the selected type can work.

As a workaround, we have added

<StaticWebAssetsEnabled>false</StaticWebAssetsEnabled>

to our project file. We aren't using Razor web pages, so this patch works for us without having to pull/edit/maintain a local copy of the WebOptimizer library.