Stream: C#/.net-collaboration

Topic: componentize-dotnet on linux

Scott Waye (Aug 29 2024 at 22:58):

@James Sturtevant Was looking into what needed changing to support linux,the first thing I see when running dotnet add package BytecodeAlliance.Componentize.DotNet.Wasm.SDK --prerelease from the readme, is that it attempts to download the compiler from

info :   NotFound https://api.nuget.org/v3-flatcontainer/microsoft.dotnet.ilcompiler.llvm/index.json 175ms

Does it need a nuget.config or something to add https://dev.azure.com/dnceng/public/_artifacts/feed/dotnet-experimental ?

James Sturtevant (Aug 29 2024 at 23:24):

oh, I might have pulled and had it cached via the compontize-dotnet repo. Can you add https://github.com/bytecodealliance/componentize-dotnet/blob/main/nuget.config to your project root and see if that fixes?

James Sturtevant (Aug 29 2024 at 23:25):

should add that step to the docs

Scott Waye (Aug 29 2024 at 23:28):

Thanks, yes that fixes the locations

Scott Waye (Aug 29 2024 at 23:29):

I can add that to the docs

James Sturtevant (Aug 30 2024 at 00:04):

I think you are right, we only need the experimental feed

James Sturtevant (Aug 30 2024 at 16:38):

was thinking, Another option would be to write that file to disk, if the native-aot option is on

Scott Waye (Aug 30 2024 at 21:52):

Might make it easier for newcomers, but would not overwrite any existing config I guess, so would work sometimes.

Scott Waye (Aug 31 2024 at 13:16):

I have a problem with dotnet build for the E2EConsumer and E2EProducer projects:

    /home/scott/.nuget/packages/microsoft.dotnet.ilcompiler.llvm/9.0.0-rc.1.24412.1/build/Microsoft.NETCore.Native.targets(361,5): error MSB3073: The command "'/tools/ilc' @"obj/Debug/net8.0/wasi-wasm/native/E2EProducer.ilc.rsp"" exited with code 127.

You can see it is not finding the path for the Ilc tools folder. What is strange is that other projects like Addr are compiling and finding Ilc successfully.

Scott Waye (Aug 31 2024 at 13:18):

I also tried building these projects directly with dotnet build from their respective directories but that gives the same error. What is the mechanism for these projects to bring in the Naot-LLVM compiler? Is it via <PackageReference Include="ByteCodeAlliance.Componentize.DotNet.Wasm.SDK" Version="$(PackageVersion)" /> ?

James Sturtevant (Aug 31 2024 at 19:44):

That just sets the version across all the projects, the sdk brings it in via https://github.com/bytecodealliance/componentize-dotnet/blob/26b5b5a839f7a2a786cfe9d2498dfa42dd6ac525/src/WasmComponent.Sdk/WasmComponent.Sdk.csproj#L34-L35

James Sturtevant (Aug 31 2024 at 19:45):

the e2e test projects can be finicky since the are relying on the local package, i've found clearing caches sometimes helps. and it seem to always work in CI since its a clean env

Scott Waye (Aug 31 2024 at 23:41):

THanks, cleaning the caches did it.

James Sturtevant (Sep 06 2024 at 22:43):

@Scott Waye saw you are pushing some changes, I got it working locally

James Sturtevant (Sep 06 2024 at 22:45):

you beat me to it by 5 mins, I pushed to your branch and was blocked

James Sturtevant (Sep 06 2024 at 22:46):

this is the diff I came up with

 <?xml version="1.0" encoding="utf-8"?>
 <configuration>
   <packageSources>
-    <add key="dev" value="..\PackageTest\packages" />
+    <add key="dev" value="../PackageTest/packages" />
   </packageSources>
   <packageSourceMapping>
     <packageSource key="dev">
-      <package pattern="BytecodeAlliance.Componentize.DotNet.WitBindgen" />
-      <package pattern="BytecodeAlliance.Componentize.DotNet.Wasm.SDK" />
+      <package pattern="BytecodeAlliance.Componentize.*" />
+      <package pattern="BytecodeAlliance.Componentize.*" />
     </packageSource>
   </packageSourceMapping>
 </configuration>

Scott Waye (Sep 07 2024 at 00:17):

Ah yes. I can close this thread now. Thanks for the review.

Matt Fisher (Sep 18 2024 at 18:14):

Hey! If I'm compiling a project from a fresh machine following componentize-dotnet's README, I run into two errors:

https://github.com/bytecodealliance/componentize-dotnet

><> dotnet build
Restore complete (0.3s)
You are using a preview version of .NET. See: https://aka.ms/dotnet-support-policy
  hello-wasm failed with 1 error(s) (0.1s) → bin/Debug/net9.0/wasi-wasm/hello-wasm.dll
    /home/bacongobbler/.nuget/packages/microsoft.dotnet.ilcompiler.llvm/9.0.0-rc.1.24429.1/build/Microsoft.NETCore.Native.targets(361,5): error MSB3073: The command ""\tools\\ilc" @"obj/Debug/net9.0/wasi-wasm/native/hello-wasm.ilc.rsp"" exited with code 127.

Build failed with 1 error(s) in 0.6s

Easy enough... Just need to add <SelfContained>true</SelfContained> to the PropertyGroup.

But then I hit this afterwards:

><> dotnet build
Restore complete (0.3s)
You are using a preview version of .NET. See: https://aka.ms/dotnet-support-policy
  hello-wasm failed with 1 error(s) (0.1s) → bin/Debug/net9.0/wasi-wasm/hello-wasm.dll
    /home/bacongobbler/.nuget/packages/microsoft.dotnet.ilcompiler.llvm/9.0.0-rc.1.24429.1/build/Microsoft.NETCore.Native.targets(361,5): error MSB3073: The command ""\tools\\ilc" @"obj/Debug/net9.0/wasi-wasm/native/hello-wasm.ilc.rsp"" exited with code 127.

Build failed with 1 error(s) in 0.6s

Is there a package missing from the README or a step I'm missing?

This is from WSL2 FYI. https://github.com/bytecodealliance/componentize-dotnet/pull/45 was merged 2 weeks ago so I assume this should work on Linux?

Scott Waye (Sep 18 2024 at 18:37):

We could do with surfacing the underlying error..

Scott Waye (Sep 18 2024 at 18:40):

And yes should work. adding /bl would get you a binlog which should have the underlying error I hope.

Matt Fisher (Sep 18 2024 at 18:49):

Here's the binlog:

msbuild.binlog

James Sturtevant (Sep 18 2024 at 19:18):

this looks similiar too https://github.com/dotnet/runtime/issues/106845

James Sturtevant (Sep 18 2024 at 19:20):

I think i noticed some issues with the latest .net 9 sdk pacakges (like needing <SelfContained>true</SelfContained>) have you tired with .net 8?

James Sturtevant (Sep 18 2024 at 19:20):

we are using 9.0.100-preview.4.24267.66 in CI where it is passing

Matt Fisher (Sep 18 2024 at 19:24):

I have not tried with .NET 8. Let me see if I can install an earlier preview release. I think the BCA blog post from Eric Gregory recommended .NET 9 preview 7. If that fails I'll fall back to .NET 8.

https://bytecodealliance.org/articles/simplifying-components-for-dotnet-developers-with-componentize-dotnet

James Sturtevant (Sep 18 2024 at 19:25):

yea, I think something changed from preview7 to the RC you are using...

James Sturtevant (Sep 18 2024 at 19:29):

also opened https://github.com/bytecodealliance/componentize-dotnet/pull/47 to see if run into it CI

Scott Waye (Sep 18 2024 at 19:30):

If RC is the problem, it _might_ get fixed with the latest merge, which might break something else :-)

James Sturtevant (Sep 18 2024 at 19:34):

looks like RC passed in CI

Matt Fisher (Sep 18 2024 at 19:38):

Oddly switching to preview.7 didn't work for me. It does appear to be installing microsoft.dotnet.ilcompiler.llvm/9.0.0-rc.1.24429.1 regardless of the SDK version I choose, but that seems normal

Matt Fisher (Sep 18 2024 at 19:43):

.NET 8 fails outright:

/home/bacongobbler/.dotnet/sdk/8.0.401/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.TargetFrameworkInference.targets(166,5): error NETSDK1045: The current .NET SDK does not support targeting .NET 9.0.  Either target .NET 8.0 or lower, or use a version of the .NET SDK that supports .NET 9.0. Download the .NET SDK from https://aka.ms/dotnet/download [/home/bacongobbler/code/hello-wasm/hello-wasm.csproj]

James Sturtevant (Sep 18 2024 at 19:45):

you would need to change your <TargetFramework> in the project your working on

Matt Fisher (Sep 18 2024 at 19:45):

Oh right

James Sturtevant (Sep 18 2024 at 19:46):

do you have a simple project that reproduces this?

Matt Fisher (Sep 18 2024 at 19:47):

Sure! Here it is: https://github.com/bacongobbler/hello-wasm

Matt Fisher (Sep 18 2024 at 19:49):

It's just from following the steps in the README + adding the <SelfContained> tag in the PropertyGroup

Matt Fisher (Sep 18 2024 at 19:57):

If it helps, it looks like the tools directory in that package doesn't contain ilc for me:

><> tree ~/.nuget/packages/microsoft.dotnet.ilcompiler.llvm/9.0.0-rc.1.24429.1/tools
/home/bacongobbler/.nuget/packages/microsoft.dotnet.ilcompiler.llvm/9.0.0-rc.1.24429.1/tools
└── netstandard
    ├── ILCompiler.Build.Tasks.deps.json
    ├── ILCompiler.Build.Tasks.dll
    └── ILCompiler.Build.Tasks.pdb

1 directory, 3 files

><> uname -a
Linux ultralisk 5.15.153.1-microsoft-standard-WSL2 #1 SMP Fri Mar 29 23:14:13 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Scott Waye (Sep 18 2024 at 20:00):

Matt Fisher said:

If it helps, it looks like the tools directory in that package doesn't contain ilc for me:

><> tree ~/.nuget/packages/microsoft.dotnet.ilcompiler.llvm/9.0.0-rc.1.24429.1/tools
/home/bacongobbler/.nuget/packages/microsoft.dotnet.ilcompiler.llvm/9.0.0-rc.1.24429.1/tools
└── netstandard
    ├── ILCompiler.Build.Tasks.deps.json
    ├── ILCompiler.Build.Tasks.dll
    └── ILCompiler.Build.Tasks.pdb

1 directory, 3 files

><> uname -a
Linux ultralisk 5.15.153.1-microsoft-standard-WSL2 #1 SMP Fri Mar 29 23:14:13 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

That's normal, ilc is under the runtime... package

Scott Waye (Sep 18 2024 at 20:01):

From the binlog, the path for the ilc tools is not getting set

Matt Fisher (Sep 18 2024 at 20:02):

Oh! This is interesting. It looks like it pulled down the win-x64 runtime package.

><> pwd
/home/bacongobbler/.nuget/packages
><> ls | grep runtime
runtime.wasi-wasm.microsoft.dotnet.ilcompiler.llvm
runtime.win-x64.microsoft.dotnet.ilcompiler.llvm

Scott Waye (Sep 18 2024 at 20:03):

You can manually set it as a property IlcHostPackagePath

Matt Fisher (Sep 18 2024 at 20:03):

I've seen some tools get confused in WSL when it tries to identify the correct OS.

Scott Waye (Sep 18 2024 at 20:04):

Matt Fisher said:

Oh! This is interesting. It looks like it pulled down the win-x64 runtime package.

><> pwd
/home/bacongobbler/.nuget/packages
><> ls | grep runtime
runtime.wasi-wasm.microsoft.dotnet.ilcompiler.llvm
runtime.win-x64.microsoft.dotnet.ilcompiler.llvm

yes, that looks wrong

Scott Waye (Sep 18 2024 at 20:05):

FWIW I use the debian WSL distro

Matt Fisher (Sep 18 2024 at 20:09):

dotnet add package runtime.linux-x64.Microsoft.DotNet.ILCompiler.LLVM --prerelease did the trick.

James Sturtevant (Sep 18 2024 at 20:10):

I did produce this on my ubuntu machine that is not wsl

Matt Fisher (Sep 18 2024 at 20:10):

Sigh. Yet another reason to switch back to native Ubuntu

Matt Fisher (Sep 18 2024 at 20:10):

Thanks everyone.

James Sturtevant (Sep 18 2024 at 20:11):

no sorry, I am reproducing the same error

James Sturtevant (Sep 18 2024 at 20:11):

/usr/bin/sh: 2: /tmp/MSBuildTempjstur/tmpcbd7e4d2750c427b9e4559c9bbdb1689.exec.cmd: \tools\ilc: not found
/home/jstur/.nuget/packages/microsoft.dotnet.ilcompiler.llvm/9.0.0-rc.1.24429.1/build/Microsoft.NETCore.Native.targets(361,5): error MSB3073: The command ""\tools\\ilc" @"obj/Debug/net8.0/wasi-wasm/native/hello-wasm.ilc.rsp"" exited with code 127. [/home/jstur/projects/components/hello-wasm/hello-wasm.csproj]

Build FAILED.

James Sturtevant (Sep 18 2024 at 20:16):

looks like 9.0.0-rc.1.24468.1 is the version that works...

James Sturtevant (Sep 18 2024 at 20:19):

what I don't get is why its working in CI...

Matt Fisher (Sep 18 2024 at 20:21):

Indeed. That does seem like an odd discrepancy... What is different in CI than what's available locally?

Is your machine pulling runtime.win-x64 as well, or something else?

James Sturtevant (Sep 18 2024 at 20:24):

hmmm, maybe it has to do with building on Windows/LInux for the final package

Scott Waye (Sep 18 2024 at 20:31):

Same here, it pulls the windows package

info :   GET https://pkgs.dev.azure.com/dnceng/9ee6d478-d288-47f7-aacc-f6e6d082ae6d/_packaging/fe324174-469a-4296-a9cb-1fd885bb6f2b/nuget/v3/flat2/runtime.win-x64.microsoft.dotnet.ilcompiler.llvm/9.0.0-rc.1.24429.1/runtime.win-x64.microsoft.dotnet.ilcompiler.llvm.9.0.0-rc.1.24429.1.nupkg

Scott Waye (Sep 18 2024 at 20:32):

for dotnet add package BytecodeAlliance.Componentize.DotNet.Wasm.SDK --prerelease

James Sturtevant (Sep 18 2024 at 20:34):

I think since the final package is built on Windows, it's selecting the wrong package to import at that time

James Sturtevant (Sep 18 2024 at 20:35):

these lines: https://github.com/bytecodealliance/componentize-dotnet/blob/788fa6a3e94947c12b8e325e3008632b3719c74b/src/WasmComponent.Sdk/WasmComponent.Sdk.csproj#L34-L35

Scott Waye (Sep 18 2024 at 20:37):

Seems like it, as the nuspec has the windows dependency

Last updated: Dec 13 2025 at 17:03 UTC