-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Some .c and .h files are being published for non-blazorwasm apps #48016
Comments
Tagging subscribers to 'arch-wasm': @lewing Issue Details
Expected ResultsOnly the files necessary to load the blazor app are in the publish folder Actual ResultsThere are 3
These files shouldn't be published to the output folder.
|
This seems to be intentional: #43785 (review). I think if we don't need the intermediate files, one cleaner option is that we separate out the "runtime pack with intermediates" from "standard runtime pack" (as the former is not for the common use-case for end-users, and requires WebAssembly compiler toolchain to be installed; to be able to relink with different arguments). e.g. cc @vargaz BTW, here is the complete diff between net5 and net6 (6.0.0-preview.2.21105.12; 0429344) --- net5
+++ net6
System.Runtime.CompilerServices.Unsafe.dll
System.Runtime.CompilerServices.Unsafe.dll.br
System.Runtime.CompilerServices.Unsafe.dll.gz
-System.Runtime.InteropServices.RuntimeInformation.dll
-System.Runtime.InteropServices.RuntimeInformation.dll.br
-System.Runtime.InteropServices.RuntimeInformation.dll.gz
System.Text.Encodings.Web.dll
System.Text.Encodings.Web.dll.br
System.Text.Encodings.Web.dll.gz
System.Text.Json.dll
System.Text.Json.dll.br
System.Text.Json.dll.gz
+binding_support.js
+binding_support.js.br
+binding_support.js.gz
blazor.boot.json
blazor.boot.json.br
blazor.boot.json.gz
@@ -106,15 +106,30 @@
my-blazor-app.dll
my-blazor-app.dll.br
my-blazor-app.dll.gz
-dotnet.5.0.0.js
-dotnet.5.0.0.js.br
-dotnet.5.0.0.js.gz
+corebindings.c
+corebindings.c.br
+corebindings.c.gz
+dotnet.6.0.0-preview.2.21105.12.js
+dotnet.6.0.0-preview.2.21105.12.js.br
+dotnet.6.0.0-preview.2.21105.12.js.gz
dotnet.timezones.blat
dotnet.timezones.blat.br
dotnet.timezones.blat.gz
dotnet.wasm
dotnet.wasm.br
dotnet.wasm.gz
+dotnet_support.js
+dotnet_support.js.br
+dotnet_support.js.gz
+driver.c
+driver.c.br
+driver.c.gz
+emcc-flags.txt
+emcc-flags.txt.br
+emcc-flags.txt.gz
+emcc-version.txt
+emcc-version.txt.br
+emcc-version.txt.gz
icudt.dat
icudt.dat.br
icudt.dat.gz
@@ -127,3 +142,18 @@
icudt_no_CJK.dat
icudt_no_CJK.dat.br
icudt_no_CJK.dat.gz
+library_mono.js
+library_mono.js.br
+library_mono.js.gz
+pal_random.js
+pal_random.js.br
+pal_random.js.gz
+pinvoke-table.h
+pinvoke-table.h.br
+pinvoke-table.h.gz
+pinvoke.c
+pinvoke.c.br
+pinvoke.c.gz
+pinvoke.h
+pinvoke.h.br
+pinvoke.h.gz |
We need those files to compile the final dotnet executable, at least driver.c needs to stay a source file since its compiled with -D defines during the build. Maybe we can get them from the runtime pack instead of the publish dir. Not sure how they end up in the final app, we create the final app ourself in the bin/Release/AppBundle directory which doesn't contain these files. |
Looks like in https://github.com/dotnet/sdk/blob/9ccce1ee9788b8267e0242f73b74bf9766bb20d0/src/BlazorWasmSdk/Targets/Microsoft.NET.Sdk.BlazorWebAssembly.Current.targets, due to line 95 and line 211, everything under Also, (unless it was intentional) the missing |
It isn't problematic. This assembly is no longer necessary. In |
By the way, we could change the SDK to have be more deliberate about what files are included (.dat, .blat, and the dotnet.wasm file). The SDK's globbing is very permissive today and there's no reason we couldn't flip it around |
I believe this is intentional with the reasoning being that the runtime gets to pick what is and what isn't included in the output of the application. If the file is in the right directory of the runtimepack, the intention is it is needed at runtime. We had similar conversations about |
There's still a bunch of these in the runtime: The SDK explicitly omits them:
Note: Still here in 6.0 |
The fact that the files are in the runtime pack does not mean they need to be in publish folder. Doing the work in |
It looks like #41966 was undone for runtime/src/installer/pkg/sfx/Microsoft.NETCore.App/Microsoft.NETCore.App.Runtime.sfxproj Lines 107 to 109 in 6c8f9ff
The |
so what is the correct place for architecture-specific files needed to create the publishable runtime? |
Some of these are temporary build files, we probably need some msbuild magic to store them in temporary obj/ folder |
We probably just need a property next to: runtime/src/mono/wasm/wasm.proj Line 13 in caa00d4
MicrosoftNetCoreAppRuntimePackSourceDir: $([MSBuild]::NormalizeDirectory('$(MicrosoftNetCoreAppRuntimePackRidDir)', 'source') and then adjust this item group: runtime/src/mono/wasm/wasm.proj Lines 83 to 111 in caa00d4
driver.c and friends will look for {package-path}/source/ instead of {package-path}/native/ .
|
I believe we will need to "make one up", like @am11 is suggesting above. I don't believe there is already a "canonical" place for these kinds of assets. Looking deeper into how this works, another possibility would be to remove these files from the I believe @dsplaisted or @ericstj should be able to give guidance here on what the correct approach is for files that ship in the runtimepack, but aren't supposed to be published to the end user's publish folder. |
that should already be fixed on master |
I think that it's correct that you can just remove the files from RuntimeList.xml if you don't want them published. If other tooling needs those files, then it will need to find them somehow. You could do it by convention, looking in the same folder as some runtime asset, or in a different folder relative to that folder if that's cleaner. We also might want to update the RuntimeList.xml format so it can express different types of assets. Probably in that case we'd update the ResolveRuntimePackAssets task output the different assets in different MSBuild items. |
FYI - this was also logged in ASP.NET - dotnet/aspnetcore#32744. |
This is not an issue for blazorwasm projects anymore, as it is skipping those files. So, moving this to 7.0.0, to fix for non-blazorwasm projects. |
We need to decide on a resolution to this so that the various bundlers can share it. |
This is being handled currently, but in a hacky manner. And we have an approach in mind, but that will get implemented in .net8 . |
This is resolved in Wasm SDK |
dotnet new blazorwasm
dotnet publish -c Release
Expected Results
Only the files necessary to load the blazor app are in the publish folder
Actual Results
There are 3
.c
files and 2.h
files inbin\Release\net6.0\publish\wwwroot\_framework
:These files shouldn't be published to the output folder.
cc @lewing @CoffeeFlux
The text was updated successfully, but these errors were encountered: