net9 - Build a RCL fails if multiple files with same name but different extensions are under wwwroot
Closed this issue · 28 comments
Is there an existing issue for this?
- I have searched the existing issues
Describe the bug
We have a RCL which produce multiple scripts, fonts, styles etc.. under the wwwroot directory in order to ship them along the NuGet package and consume from aspnet blazor projects.
Each of these files have "gzip" and "brotli" compression version with the filename "[name].[ext].[compressionextension]", so for example "interops.js" have "interops.js.gz" and "interops.js.br" files.
Until net8 it works good, but after update to net9 the build fails with and exception from StaticWebAssets.targets.
Deleting the "compressed version" ones the build completes.
Expected Behavior
We expect the same behavior of net8 build.
Steps To Reproduce
- Create a RCL;
- Create a wwwroot folder;
- Create script file named "test.js":
- Create different extension-named version like "test.js.br" and "test.js.gz":
- Try to build project:
Exceptions (if any)
Thrown from C:\Program Files\dotnet\sdk\9.0.100-rc.2.24474.11\Sdks\Microsoft.NET.Sdk.StaticWebAssets\targets\Microsoft.NET.Sdk.StaticWebAssets.targets(634,5):
InvalidOperationException: Sequence contains more than one element
at System.Linq.Enumerable.SingleOrDefault[TSource](IEnumerable`1 source)
at Microsoft.AspNetCore.StaticWebAssets.Tasks.GenerateStaticWebAssetsDevelopmentManifest.<ComputeManifestAssets>d__19.MoveNext()
at System.Linq.Buffer`1..ctor(IEnumerable`1 source)
at System.Linq.Enumerable.ToArray[TSource](IEnumerable`1 source)
at Microsoft.AspNetCore.StaticWebAssets.Tasks.GenerateStaticWebAssetsDevelopmentManifest.ComputeDevelopmentManifest(IEnumerable`1 assets, IEnumerable`1 discoveryPatterns)
at Microsoft.AspNetCore.StaticWebAssets.Tasks.GenerateStaticWebAssetsDevelopmentManifest.Execute()
.NET Version
9.0.100-rc.2.24474.11
Anything else?
.NET SDK:
Version: 9.0.100-rc.2.24474.11
Commit: 315e1305db
Workload version: 9.0.100-manifests.3424025a
MSBuild version: 17.12.0-preview-24473-03+fea15fbd1
Runtime Environment:
OS Name: Windows
OS Version: 10.0.22631
OS Platform: Windows
RID: win-x64
Base Path: C:\Program Files\dotnet\sdk\9.0.100-rc.2.24474.11\
.NET workloads installed:
[aspire]
Installation Source: SDK 9.0.100-rc.2, VS 17.12.35424.110
Manifest Version: 8.2.2/8.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.aspire\8.2.2\WorkloadManifest.json
Install Type: Msi
[wasm-tools]
Installation Source: SDK 9.0.100-rc.2, VS 17.12.35424.110
Manifest Version: 9.0.0-rc.2.24473.5/9.0.100-rc.2
Manifest Path: C:\Program Files\dotnet\sdk-manifests\9.0.100-rc.2\microsoft.net.workload.mono.toolchain.current\9.0.0-rc.2.24473.5\WorkloadManifest.json
Install Type: Msi
Configured to use loose manifests when installing new manifests.
Host:
Version: 9.0.0-rc.2.24473.5
Architecture: x64
Commit: 990ebf52fc
.NET SDKs installed:
8.0.403 [C:\Program Files\dotnet\sdk]
9.0.100-rc.2.24474.11 [C:\Program Files\dotnet\sdk]
.NET runtimes installed:
Microsoft.AspNetCore.App 8.0.10 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 9.0.0-rc.2.24474.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 8.0.10 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.0-rc.2.24473.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 8.0.10 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 9.0.0-rc.2.24474.4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Other architectures found:
x86 [C:\Program Files (x86)\dotnet]
registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]
Environment variables:
Not set
global.json file:
Not found
Learn more:
https://aka.ms/dotnet/info
Download .NET:
https://aka.ms/dotnet/download
Can confirm that I have the same issue, tested with released .net9.
+1
Upgraded a net8.0 project that uses https://github.com/AnderssonPeter/CompressedStaticFiles to net9.0 and I'm getting this build error with dotnet sdk 9.0.100. I've made no code changes thus far; I am not using the new .MapStaticAssets() feature
Workaround was to rename the wwwroot folder to anything else and replace app.UseCompressedStaticFiles() with app.UseCompressedStaticFiles(location: "<whatever_you_renamed_wwwroot_to>")
Same issue, working net8.0 project, upgraded to net9.0 just now and getting this too.
/usr/share/dotnet/sdk/9.0.100/Sdks/Microsoft.NET.Sdk.StaticWebAssets/targets/Microsoft.NET.Sdk.StaticWebAssets.targets(634,5):
error : InvalidOperationException: Sequence contains more than one element [/Website/Website.csproj]
....
/usr/share/dotnet/sdk/9.0.100/Sdks/Microsoft.NET.Sdk.StaticWebAssets/targets/Microsoft.NET.Sdk.StaticWebAssets.targets(634,5):
error : at Microsoft.AspNetCore.StaticWebAssets.Tasks.GenerateStaticWebAssetsDevelopmentManifest.Execute()
+1
same here
Haven't had the opportunity to debug this my self yet. But it seems like this is were things explode https://github.com/dotnet/sdk/blob/2d87cb8327aa0d998bc5a5e34cbcf6585c8dc5af/src/StaticWebAssetsSdk/Tasks/GenerateStaticWebAssetsDevelopmentManifest.cs#L66
For history:
var assetsWithPathSegments = ComputeManifestAssets(assets).ToArray();
We're experiencing the same issue, when we include the output from a webpack build in our wwwroot directory for a blazor wasm project. We're not using either MapStaticAssets() nor UseCompressedStaticFiles(). Are there any viable workarounds? Would it be preferred to publish files (from webpack) as non optimized and let the build task do it's thing instead?
I had the same issue. Disabling gzip in bundlerconfig.json and removing *.*.gzip files in wwwroot, resolved it.
{
"outputFileName": "wwwroot/css/app.css",
"inputFiles": [
"Styles/app.css"
],
"minify": {
"enabled": true,
"gzip": false ←
}
},
@rmin001 I confirm that only gzipped files cause the problem.. if I disable gzip and keep only brotli compression through webpack the build works
@asabia we have the same configuration as you but the assets then will be pushed to cdn storage so our workaround was to exclude the scripts "as content" and include then in the nuget package through csproj. But then the issue moved to the project which has the reference to the library with another exception always related to a duplicated file under wwwroot directory..
Having same issue disabling GZip isn't a option guess ill wait to come from NET 8
I'm also experiencing this error. This makes it impossible for most apps to migrate to .NET 9. Even having both the regular and minified version of a static asset (like css or js) seems to trigger the error. We need a fix or workaround.
Haven't had the opportunity to debug this my self yet. But it seems like this is were things explode dotnet/sdk@
2d87cb8/src/StaticWebAssetsSdk/Tasks/GenerateStaticWebAssetsDevelopmentManifest.cs#L66For history:
var assetsWithPathSegments = ComputeManifestAssets(assets).ToArray();We're experiencing the same issue, when we include the output from a webpack build in our wwwroot directory for a blazor wasm project. We're not using either
MapStaticAssets()norUseCompressedStaticFiles(). Are there any viable workarounds? Would it be preferred to publish files (from webpack) as non optimized and let the build task do it's thing instead?
Seems to explode a step deeper on the Single:
https://github.com/dotnet/sdk/blob/262b9c3d6cf67287f649e38d83e6c5d9d08feb8a/src/StaticWebAssetsSdk/Tasks/GenerateStaticWebAssetsDevelopmentManifest.cs#L105
Ps: this got changed 3 weeks ago: dotnet/sdk@825b59e#diff-3a76e81cb491f70d5c0256f4e335a13e9e42a8f2033a55d04c4ede53a307dd82R105
Sorry for replying again... You can detect files with identical names but different extensions with the following:
grep -oP "(?<=<RelativePath>).*(?=</RelativePath>)" YourProject/obj/Release/net9.0/staticwebassets/msbuild.YourProject.Microsoft.AspNetCore.StaticWebAssets.props | sed 's/\.[^.]*$//' | sort | uniq -c | lessIt will list duplicate files on top, replace YourProject with the correct name ;)
Sadly enough, even with no duplicates this fails for me
In my case offending files were sitemap.xml and sitemap.xml.gz in wwwroot
Thanks for contacting us.
What's likely happening here is that there is another compression system that is conflicting with the built-in compression support we've added. We have a separate issue to better detect external pre-compressed assets #57518 but there are two things you can do:
- Set
<CompressionEnabled>false</CompressionEnabled>in the csproj file to disable the built-in compression. - Disable/exclude compression on your system and let the built-in system handle it.
If you still have issues after that, please let us know.
Thanks for contacting us.
What's likely happening here is that there is another compression system that is conflicting with the built-in compression support we've added. We have a separate issue to better detect external pre-compressed assets #57518 but there are two things you can do:
- Set
<CompressionEnabled>false</CompressionEnabled>in the csproj file to disable the built-in compression.- Disable/exclude compression on your system and let the built-in system handle it.
If you still have issues after that, please let us know.
This dosen't happen on NET 8 tho only NET 9
@javiercn thank you, I was waiting for a confirmation.
In the meanwhile I had already removed our compression through webpack by leaving all the things to dotnet, and the RCL build successfully.
The issues now are in the blazor hosted project which builds with strange warnings and in some case errors but for these I will open new issues.
Suggestion:
Since there is a section here dedicated to the new management of static files, I think that this case have to be documented with the two solutions.
@Dona278 we are evaluating whether to patch this to ease-in the migration. The reason we originally didn't include it in 9.0 is that it's a one liner to turn off compression in the SDK, but we recognize that its better if this works out of the box, we simply didn't have data about how prevalent this was going to be.
In general, we think that it's best if you leave compression to the SDK instead of relying on external tools / pre-compressed bundles as you don't know to which level those assets have been compressed.
In general, we think that it's best if you leave compression to the SDK instead of relying on external tools / pre-compressed bundles as you don't know to which level those assets have been compressed.
wwwroot can contain static files and it makes zero sense to compress them again and again at build time or runtime. SDK just has to take into account that some assets can already be compressed and at least not fail build, print warning for example. Suggested approach only takes efforts but does not add any value.
I did not explicitly enable build time compression but suddenly it fails build with no meaningful message, not good.
Also, why this is labeled as blazor area? It happens in any web project with wwwroot folder.
We have an old MVC app that has gone through .net core 1 -> 8 so far, nothing related to Blazor, and this has hit us.
The only compression I can find in our project is some Microsoft.AspNetCore.ResponseCompression.
We "solved" this by renaming wwwroot to www and changing the content folder. Far from a solution, but at least we are back in production now.
I can't understand how this one got through testing though... Our project is not so advanced to trigger these issues
There's a candidate PR now to address this dotnet/sdk#44976
We have an old MVC app that has gone through .net core 1 -> 8 so far, nothing related to Blazor, and this has hit us.
The only compression I can find in our project is some
Microsoft.AspNetCore.ResponseCompression.We "solved" this by renaming
wwwroottowwwand changing the content folder. Far from a solution, but at least we are back in production now.I can't understand how this one got through testing though... Our project is not so advanced to trigger these issues
This is a shared feature between Blazor and MVC/Razor pages.
Turning the default compression off with <CompressionEnabled>false</CompressionEnabled> in the relevant projects should be enough to unblock you, if that's not the case, please file a separate issue and we'll investigate.
In general, we think that it's best if you leave compression to the SDK instead of relying on external tools / pre-compressed bundles as you don't know to which level those assets have been compressed.
wwwroot can contain static files and it makes zero sense to compress them again and again at build time or runtime. SDK just has to take into account that some assets can already be compressed and at least not fail build, print warning for example. Suggested approach only takes efforts but does not add any value.
I did not explicitly enable build time compression but suddenly it fails build with no meaningful message, not good.
Also, why this is labeled as blazor area? It happens in any web project with wwwroot folder.
This is a shared feature between MVC/Blazor/Razor pages.
wwwroot can contain static files and it makes zero sense to compress them again and again at build time or runtime
We don't expect most files to be compressed on existing apps, as this take extra effort to setup, and a large portion of people simply doesn't do it. You can always turn compression off for individual assets that are already compressed or turn off the entire compression feature in the SDK and handle compression by yourself.
The framework only compresses files once during build/publish, it does not re-compress files on every build, nor does it do any compression at runtime.
@Dona278 we are evaluating whether to patch this to ease-in the migration. The reason we originally didn't include it in 9.0 is that it's a one liner to turn off compression in the SDK, but we recognize that its better if this works out of the box, we simply didn't have data about how prevalent this was going to be.
In general, we think that it's best if you leave compression to the SDK instead of relying on external tools / pre-compressed bundles as you don't know to which level those assets have been compressed.
Yes of course, but if it was mentioned in the announcement that "now the SDK perform compression for you at build / publish time" probably I wouldn't have opened an issue, lost 1 days to try to debug and understand the reason and to find a workaround and maybe I could (say I but this is for all user who read this issue) simply remove our self-made-compression or use the unknown (for me) <CompressionEnabled>false</CompressionEnabled> one-line of the csproj.
I suggest this only just to reduce effort between dotnet major release migrations of projects that aren't simple examples with default behaviors (compression is only one of the features that were changed among dotnet releases and users may have filled the gap by self implemented something).
However for me use a solution or another resolve this issue.
@Dona278 Sorry if it was not clear, I filed an issue to make sure that this gets documented on the appropriate places.
but we recognize that its better if this works out of the box, we simply didn't have data about how prevalent this was going to be.
Just fyi, I think this has the potential to be fairly prevalent as in our case it was a libman.json entry that pulled in a package that included .gz assets, which is certainly not uncommon for web packages.
In my project, there is a file named 'WebUI.styles.css' in the wwwroot folder. When I excluded it from the project, my project worked fine.