Some .c and .h files are being published for non-blazorwasm apps

[eerhardt]

1. Install the latest https://github.com/dotnet/installer#installers-and-binaries
2. dotnet new blazorwasm
3. 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 in bin\Release\net6.0\publish\wwwroot\_framework:

• corebindings.c
• driver.c
• pinvoke.c
• pinvoke.h
• pinvoke-table.h

These files shouldn't be published to the output folder.

cc @lewing @CoffeeFlux

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

1. Install the latest https://github.com/dotnet/installer#installers-and-binaries
2. dotnet new blazorwasm
3. 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 in bin\Release\net6.0\publish\wwwroot\_framework:

• corebindings.c
• driver.c
• pinvoke.c
• pinvoke.h
• pinvoke-table.h

These files shouldn't be published to the output folder.

cc @lewing @CoffeeFlux

Author:	eerhardt
Assignees:	-
Labels:	arch-wasm
Milestone:	-

[am11]

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. ./build.sh -os browser -c Release will not put these intermediate artifacts in artifacts//bin/native/net6.0-Browser-Release-wasm/src/, but, say a new OS, ./build.sh -os browser-extras -c Release will. This way, we will not need to modify src/installer/pkg/sfx/Microsoft.NETCore.App/Directory.Build.props, as that is a flat whitelist of 'all possible files' and sfx targets (in arcade) validate the other way around; all files in destination directory (in this case artifacts//bin/native/net6.0-Browser-Release-wasm/src/) are present in the whitelist. So if a subset (like clr or mono) doesn't produce all those files, it is fine.

cc @vargaz

BTW, here is the complete diff between net5 and net6 (6.0.0-preview.2.21105.12; 0429344) wwwroot/_framework directories:

--- 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

[vargaz]

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.

[am11]

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 ~/.nuget/packages/microsoft.netcore.app.runtime.browser-wasm/6.0.0-preview.2.21105.12/runtimes/browser-wasm/native gets copied to publish dir's wwwroot/_framework/. We can copy these additional *.c and *.h files somewhere else, say runtimes/browser-wasm/sources instead of runtimes/browser-wasm/native in this package without changing the SDK. Would that work?

Also, (unless it was intentional) the missing System.Runtime.InteropServices.RuntimeInformation.dll from .NET6 publish directory could be problematic.

[eerhardt]

Also, (unless it was intentional) the missing System.Runtime.InteropServices.RuntimeInformation.dll from .NET6 publish directory could be problematic.

It isn't problematic. This assembly is no longer necessary. In net5.0, AspNetCore.Components was using the RuntimeInformation.IsOSPlatform method from this assembly. In net6.0, that code has been changed to use the new OperatingSystem.IsXXX() methods. See dotnet/aspnetcore#28233.

[pranavkm]

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

[eerhardt]

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 .a files and removed them in #41966.