bumps tools to latest versions

[cataggar]

No description provided.

[jsturtevant]

This looks good to me. We can merge this and follouw up on wkg later if needed.

[cataggar]

Sounds good.

[GerardSmit]

Should NativeAOT-LLVM also be bumped?

In bytecodealliance/wit-bindgen the CI is running WASI SDK 27 + the latest version of NativeAOT-LLVM (there is no fixed version). WASI SDK 27 is tested with this version. I'm not sure if the current version (10.0.0-alpha.1.25162.1) is fully tested with WASI SDK 27.

The latest version can be checked here: https://dev.azure.com/dnceng/public/_artifacts/feed/dotnet-experimental/NuGet/Microsoft.DotNet.ILCompiler.LLVM
Which is: 10.0.0-preview.2.25455.1

[GerardSmit]

Ah... It seems like the target CheckWasmSdks was renamed to ValidateWasiSdk in dotnet/runtimelab#3157.

Because of this, the WASI SDK isn't being set anymore (BeforeTargets="CheckWasmSdks"):

componentize-dotnet/src/WitBindgen/build/BytecodeAlliance.Componentize.DotNet.WitBindgen.targets

Lines 23 to 27 in b132a2a

	<Target Name="PrepareWasmSdks" BeforeTargets="CheckWasmSdks" DependsOnTargets="ObtainWasiSdk">
	<PropertyGroup>
	<WASI_SDK_PATH>$(WasiSdkRoot)</WASI_SDK_PATH>
	</PropertyGroup>
	</Target>

Maybe this needs to be renamed to ValidateWasiSdk (or CompileWasmObjects)?

/cc @SingleAccretion

[cataggar]

Looks like a WASI_SDK_PATH is now required.

/home/runner/.nuget/packages/microsoft.dotnet.ilcompiler.llvm/10.0.0-preview.2.25455.1/build/Microsoft.NETCore.Native.Wasm.targets(36,5): error : Wasi SDK not found, not compiling to WebAssembly. To enable WebAssembly compilation, install Wasi SDK and ensure the WASI_SDK_PATH environment variable points to the directory containing share/wasi-sysroot [/home/runner/work/componentize-dotnet/componentize-dotnet/samples/calculator/CalculatorComposed/CalculatorComposed.csproj]

[SingleAccretion]

ValidateWasiSdk, CompileWasmObjects

All of these targets are internal implementation details of the NAOT-LLVM build packaging. I would recommend sequencing before a more public target. For example, IlcCompile.

[cataggar]

Thanks @GerardSmit & @SingleAccretion ! I updated to use IlcCompile as recommended.

What is the usual way to test these artifacts? In the build, I saw:
Artifact download URL: https://github.com/bytecodealliance/componentize-dotnet/actions/runs/17748614166/artifacts/4018054241

Recommendation is to just use a local files NuGet feed?

For my future reference, the targets are here:
https://github.com/dotnet/runtimelab/blob/feature/NativeAOT-LLVM/src/coreclr/nativeaot/BuildIntegration/Microsoft.NETCore.Native.Wasm.targets

[GerardSmit]

Recommendation is to just use a local files NuGet feed?

This is what I did to test locally (I copied the *.nupkg files in the packages folder next to the .sln-file and bumped the version).

I think you can also use the example project samples/calculator/Adder without consuming the NuGet package, since this references the *.props files directly:

componentize-dotnet/samples/calculator/Adder/Adder.csproj

Lines 3 to 4 in b132a2a

	<!-- Only needed when referencing the dependencies as projects. For package references, these are imported automatically. -->
	<Import Project="..\..\..\src\WasmComponent.Sdk\ImportInDev.proj" />

[cataggar]

Just learned about the https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-nuget-registry , so I pushed it there.

To add:

dotnet nuget add source --username $env.GH_USER --password $env.GH_TOKEN --store-password-in-clear-text --name cataggar "https://nuget.pkg.github.com/cataggar/index.json"

[cataggar]

My test project now compiles successfully with:

    <PackageReference Include="BytecodeAlliance.Componentize.DotNet.Wasm.SDK" Version="0.7.0-preview00207" />
    <PackageVersion Include="Microsoft.DotNet.ILCompiler.LLVM" Version="10.0.0-preview.2.25455.1" />
    <PackageReference Include="runtime.win-x64.microsoft.dotnet.ilcompiler.llvm" Version="10.0.0-preview.2.25455.1" />

[cataggar]

I moved this to draft after trying it out in Visual Studio Code and Visual Studio. In either, it constantly deletes and regenates the files every few seconds. You can see it when you enable this:

<WitGeneratedFilesRoot>generated/wit</WitGeneratedFilesRoot>

[jsturtevant]

Thanks @GerardSmit & @SingleAccretion ! I updated to use IlcCompile as recommended.

What is the usual way to test these artifacts? In the build, I saw: Artifact download URL: https://github.com/bytecodealliance/componentize-dotnet/actions/runs/17748614166/artifacts/4018054241 Recommendation is to just use a local files NuGet feed?

You can either download these packages from the PR or I typically create the packages locally (dotnet pack) then create a project with a nuget.config pointing to the directory. The package test in the repo also uses the freshly built packages: https://github.com/bytecodealliance/componentize-dotnet/tree/main/test/E2ETest/PackageTest

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <config>
    <add key="globalPackagesFolder" value=".packages" />
  </config>
  <packageSources>
    <!--To inherit the global NuGet package sources remove the <clear/> line below -->
    <clear />
    <add key="dotnet-experimental" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-experimental/nuget/v3/index.json" />
    <add key="nuget" value="https://api.nuget.org/v3/index.json" />
    <add key="test" value="/home/jstur/dev/packages/" />
  </packageSources>
</configuration>

Thanks for working on getting this all updated!

[cataggar]

I moved this to draft after trying it out in Visual Studio Code and Visual Studio. In either, it constantly deletes and regenates the files every few seconds.

I'm using this project only with just AI coding and without editor support. The editor support has problems for this PR, but also on main.

I think this pull request is ready to merge.

[jsturtevant]

The editor support has problems for this PR, but also on main.

Ok so this was happening prior to this? I use VS Code but hadn't noticed it. If so, Will create an issue and we can move forward here. Thanks!

[cataggar]

Yes, that is what I observed. On main I had problems in both VS Code and Visual Studio 2026. My .NET version in both cases:

> dotnet --info
.NET SDK:
 Version:           10.0.100-rc.1.25451.107
 Commit:            2db1f5ee2b

[cataggar]

Honestly, I'm not sure about what the compatibility is supposed to be between some of these. May be @GerardSmit knows. #99 looks like it may help.

[GerardSmit]

I'm not sure. Personally I'm using Rider, not VS or VS Code and I haven't had this issue.

In PR #99 I only changed the "BytecodeAlliance.Componentize.DotNet.Wasm.SDK" to a NuGet SDK project. It seems this problem is coming from "BytecodeAlliance.Componentize.DotNet.WitBindgen". So, I don't think this PR will help.

---

From what I can see; the directory is being removed but instantly after that the wit-bindgen is executed:

componentize-dotnet/src/WitBindgen/build/BytecodeAlliance.Componentize.DotNet.WitBindgen.targets

Lines 93 to 95 in b132a2a

	<RemoveDir Directories="$(WitGeneratedFilesRoot)" />
	<MakeDir Directories="$(WitGeneratedFilesRoot)" />
	<Exec Command="$(WitBindgenExe) c-sharp %(Wit.Identity) %(Wit.WitWorldArg) --runtime $(WitBindgenRuntime) $(WitBindgenAddtionalArgs) --out-dir $(WitGeneratedFilesRoot)" />

This is executed on BeforeCompile:

componentize-dotnet/src/WitBindgen/build/BytecodeAlliance.Componentize.DotNet.WitBindgen.targets

Lines 51 to 53 in b132a2a

	<Target Name="WitCompile_BeforeCsCompile" BeforeTargets="LinkNativeLlvm; BeforeCompile; "
	Condition="'$(Language)' == 'C#' AND '@(Wit)' != ''"
	DependsOnTargets="PrepareWasmSdks; WitCompile_GetDependencies; WitCompile_InvokeTool">

I'm not sure when Visual Studio executes this task. Googling and ChatGPT'ing also doesn't answer this question;

If you hook into BeforeCompile, that can get invoked (or at least your target will be evaluated or considered) even during project load / “non-build” contexts in Visual Studio — depending on how Visual Studio triggers its design-time targets and what dependencies your target has.

The only thing I can think of, is that BeforeCompile gets executed, WitBindgen generates the code, Visual Studio sees that the .cs-files are changed and compiles again, causing BeforeCompile to be fired again. However, this is a speculation since I don't have this issue.