Joel Dice (Jun 28 2024 at 17:12): Joel Dice (Jun 28 2024 at 17:12):Hi all. After a long struggle I finally got CI green for https://github.com/dotnet/runtimelab/pull/2614, but I expect there will be review feedback to address, and despite a week of trying to debug the System.Net.Http.Functional.Tests suite, it's still not clear what the right way is to add automated test coverage for the wasi:http support.
I'm wondering if, while we're sorting all that out, we should consider temporarily using my branch for componentize-dotnet builds so we can make the wasi:http support available for users to play around with. Does that sound reasonable? If so, we'll need to figure out the logistics of publishing packages from that fork and using them in componentize-dotnet, but hopefully that's not terribly painful. And of course we'd switch right back once that PR is merged.
James Sturtevant (Jun 28 2024 at 17:31):If there is a pacakge avalaible on nuget, it should be pretty straightforward to include it in componetize-dotnet
Scott Waye (Jun 28 2024 at 17:33):Fine with me
Joel Dice (Jun 28 2024 at 17:34):_James Sturtevant|625613 said:
If there is a pacakge avalaible on nuget, it should be pretty straightforward to include it in componetize-dotnet
That's what I figured. I'm going to build locally using my local build of the ILC first. BTW, what do I need to change to prevent wasm-tools component new from running (since my fork uses the wasm32-wasip2 target directly and doesn't need that step)?
Joel Dice (Jun 28 2024 at 17:35):@Scott Waye do you happen to know how I might publish nuget packages via CI from my fork? Is there some pipeline job I need to enable and credentials to set up, etc.?
James Sturtevant (Jun 28 2024 at 17:37):essentially drop these line: https://github.com/bytecodealliance/componentize-dotnet/blob/22eeed4233ec311f1f3e8f76d0ba0eb191b6ebb1/src/WasmComponent.Sdk/build/ByteCodeAlliance.Componentize.DotNet.Wasm.SDK.targets#L2-L9
Scott Waye (Jun 28 2024 at 17:41):Publish as BA , i.e. with BA's signing keys ?
Scott Waye (Jun 28 2024 at 17:41):or to dnceng with MS's keys ?
Joel Dice (Jun 28 2024 at 17:42):BA keys would probably be best. Or I guess I could create my own account since it's temporary.
Scott Waye (Jun 28 2024 at 17:43):Not sure you can do it without keys that have a valid cert chain
Scott Waye (Jun 28 2024 at 17:44):valid/trusted
Scott Waye (Jun 28 2024 at 17:48):BA keys would be easier (and cheaper) I think, does BA have its own nuget feed , or would you want them published to nuget.org? Microsoft might have something in their T&Cs about that, don't know. Annoying that infrastructure issues take so much time.
Joel Dice (Jun 28 2024 at 17:49):If this turns out to be a big pain to do, we can forget about it, BTW.
Scott Waye (Jun 28 2024 at 17:49):Like, I can't get the Linux CI build to pull in <optional> which I understand should "just work" with c++ 17
Joel Dice (Jun 28 2024 at 17:50):Strange; I haven't had trouble with that building locally for Linux. Maybe it's using an old Linux distro?
Scott Waye (Jun 28 2024 at 17:52):Could be, its an azure docker image, not sure what's in it, maybe I should try to ls -lR /usr/include (if that's where c++ gets it's headers from )
Scott Waye (Jun 28 2024 at 17:52):Its odd though as LLVM itself builds ok
Joel Dice (Jun 28 2024 at 17:53):If you can find out what docker image it's using, you could run that locally and snoop around
Joel Dice (Jun 28 2024 at 17:53):LLVM might not be using the latest C++ features (internally, I mean)
Scott Waye (Jun 28 2024 at 17:53):Its an LLVM header that pulls <optional>
Joel Dice (Jun 28 2024 at 17:54):so it builds ok, but <optional> can't be found? Where does it break, then?
Scott Waye (Jun 28 2024 at 17:55):Bulding the AOT compiler
/__w/1/s/wasm-tools/llvm-project/llvm/include/llvm/ADT/STLForwardCompat.h:20:10: fatal error: 'optional' file not found
20 | #include <optional>
| ^~~~~~~~~~
I see. Have you verified that the compiler command has -std=c++17? If not, maybe it's defaulting to an older version.
Joel Dice (Jun 28 2024 at 18:04):@James Sturtevant can you help me understand this code? https://github.com/bytecodealliance/componentize-dotnet/blob/22eeed4233ec311f1f3e8f76d0ba0eb191b6ebb1/src/WasmComponent.Sdk/WasmComponent.Sdk.csproj#L64-L82
It seems to be running tar -xf on all the files, including the win-x64.zip file, which understandably fails.
Joel Dice (Jun 28 2024 at 18:06):Although git-blame says Steve wrote that, so maybe it's a question for him. Did you ever run into that?
James Sturtevant (Jun 28 2024 at 18:10):it downloads all the files and extracts them and puts them into the nuget pacakge. I am assuming you are running it from linux? the line https://github.com/bytecodealliance/componentize-dotnet/blob/22eeed4233ec311f1f3e8f76d0ba0eb191b6ebb1/src/WasmComponent.Sdk/WasmComponent.Sdk.csproj#L70 is probably only been tested on windows
Joel Dice (Jun 28 2024 at 18:10):Correct, I'm running on Linux, but I'm not understanding how tar -xf win-x64.zip could run successfully on any platform.
James Sturtevant (Jun 28 2024 at 18:11):I think tar.exe will work on zip files on windows?
Joel Dice (Jun 28 2024 at 18:11):wow, TIL
James Sturtevant (Jun 28 2024 at 18:11):one moment, trying it
James Sturtevant (Jun 28 2024 at 18:14):yes, tar.exe will unzip with tar.exe -xf on windows, which is why i never noticed that
James Sturtevant (Jun 28 2024 at 18:20):SHould be pretty easy to fix, I can look at it in a bit if you need some help. There are likely a few other spots where OS was assumed
James Sturtevant (Jun 28 2024 at 18:22):is there a prefered unzip tool that is used on linux/mac that is installed out of the box?
Scott Waye (Jun 28 2024 at 18:30):Joel Dice said:
If you can find out what docker image it's using, you could run that locally and snoop around
Thanks I will install the image locally and poke around
Joel Dice (Jun 28 2024 at 19:10):@James Sturtevant: Do you happen to know what these errors mean?
$ dotnet build
Restore complete (0.4s)
You are using a preview version of .NET. See: https://aka.ms/dotnet-support-policy
WitBindgen succeeded (0.8s) → src/WitBindgen/bin/Debug/net8.0/WitBindgen.dll
LibraryUsingWit succeeded (0.2s) → test/WitBindgenTest/testapps/LibraryUsingWit/bin/Debug/net8.0/LibraryUsingWit.dll
WasmComponent.Sdk succeeded (0.2s) → src/WasmComponent.Sdk/bin/Debug/net8.0/WasmComponent.Sdk.dll
WitBindgenTest succeeded (0.1s) → test/WitBindgenTest/WitBindgenTest/bin/Debug/net8.0/WitBindgenTest.dll
SimpleProducer succeeded (1.1s) → test/WasmComponentSdkTest/testapps/SimpleProducer/bin/Debug/net8.0/wasi-wasm/native/simpleproducer-component.wasm
CalculatorHost succeeded (1.1s) → samples/calculator/CalculatorHost/bin/Debug/net8.0/wasi-wasm/native/calculatorhost-component.wasm
Adder succeeded (1.0s) → samples/calculator/Adder/bin/Debug/net8.0/wasi-wasm/native/adder-component.wasm
CalculatorComposed succeeded with 1 warning(s) (0.2s) → samples/calculator/CalculatorComposed/bin/Debug/net8.0/CalculatorComposed.dll
EXEC : warning : `wasm-tools compose` has been deprecated.
SimpleConsumer succeeded with 1 warning(s) (1.1s) → test/WasmComponentSdkTest/testapps/SimpleConsumer/bin/Debug/net8.0/wasi-wasm/native/simpleconsumer-component.wasm
EXEC : warning : `wasm-tools compose` has been deprecated.
AppWithWitFolder succeeded (0.9s) → test/WasmComponentSdkTest/testapps/AppWithWitFolder/bin/Debug/net8.0/wasi-wasm/native/appwithwitfolder-component.wasm
WasmComponentSdkTest succeeded (0.1s) → test/WasmComponentSdkTest/WasmComponentSdkTest/bin/Debug/net8.0/WasmComponentSdkTest.dll
PackageTest failed with 5 error(s) (6.9s) → test/E2ETest/PackageTest/bin/Debug/net8.0/PackageTest.dll
/home/dicej/p/componentize-dotnet/test/E2ETest/testapps/E2EProducer/E2EProducer.csproj : error NU1100: Unable to resolve 'ByteCodeAlliance.Componentize.DotNet.Wasm.SDK (>= 0.1.0-dev)' for 'net8.0'. PackageSourceMapping is enabled, the following source(s) were not considered: /home/dicej/p/componentize-dotnet/test/E2ETest/testapps/../PackageTest/packages, dotnet-experimental, dotnet8, nuget. [/home/dicej/p/componentize-dotnet/test/E2ETest/testapps/E2EConsumer/E2EConsumer.csproj]
/home/dicej/p/componentize-dotnet/test/E2ETest/testapps/E2EConsumer/E2EConsumer.csproj : error NU1100: Unable to resolve 'ByteCodeAlliance.Componentize.DotNet.Wasm.SDK (>= 0.1.0-dev)' for 'net8.0'. PackageSourceMapping is enabled, the following source(s) were not considered: /home/dicej/p/componentize-dotnet/test/E2ETest/testapps/../PackageTest/packages, dotnet-experimental, dotnet8, nuget.
/home/dicej/p/componentize-dotnet/test/E2ETest/testapps/E2EConsumer/E2EConsumer.csproj : error NU1100: Unable to resolve 'ByteCodeAlliance.Componentize.DotNet.Wasm.SDK (>= 0.1.0-dev)' for 'net8.0/wasi-wasm'. PackageSourceMapping is enabled, the following source(s) were not considered: /home/dicej/p/componentize-dotnet/test/E2ETest/testapps/../PackageTest/packages, dotnet-experimental, dotnet8, nuget.
/home/dicej/p/componentize-dotnet/test/E2ETest/testapps/E2EProducer/E2EProducer.csproj : error NU1100: Unable to resolve 'ByteCodeAlliance.Componentize.DotNet.Wasm.SDK (>= 0.1.0-dev)' for 'net8.0/wasi-wasm'. PackageSourceMapping is enabled, the following source(s) were not considered: /home/dicej/p/componentize-dotnet/test/E2ETest/testapps/../PackageTest/packages, dotnet-experimental, dotnet8, nuget. [/home/dicej/p/componentize-dotnet/test/E2ETest/testapps/E2EConsumer/E2EConsumer.csproj]
/home/dicej/p/componentize-dotnet/test/E2ETest/PackageTest/PackageTest.csproj(40,9): error MSB3073: The command "dotnet restore --no-cache" exited with code 1.
Build failed with 5 error(s) and 2 warning(s) in 8.4s
Here are the changes/hacks I've made to build locally on Linux: https://github.com/dicej/componentize-dotnet/commit/b040b2942f8eca9521020655ac68b21d6455db21
Joel Dice (Jun 28 2024 at 19:16):Actually, I guess I can ignore those errors for now since dotnet pack works fine.
Joel Dice (Jun 28 2024 at 19:26):Now I'm thinking I'll try publishing my own builds of both the runtime/ILC and componentize-dotnet to GitHub under my own account using https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-nuget-registry. If that works, we won't need to mess with BA keys at all for what should be a temporary situation.
James Sturtevant (Jun 28 2024 at 20:55):The e2e producer/consumer tests are there to generate a nuget package locally and test that it works. Those tests gave me a hard time too, and I thought I had ironed out the issues. It seems to not be matching the packages in via https://github.com/dicej/componentize-dotnet/blob/main/test/E2ETest/testapps/nuget.config this file. Did the name change in anyway?
Joel Dice (Jun 28 2024 at 20:57):The names shouldn't have changed, AFAIK.
Joel Dice (Jun 28 2024 at 20:58):Here's what dotnet pack produced:
ByteCodeAlliance.Componentize.DotNet.Wasm.SDK.0.1.0-dev.nupkg
ByteCodeAlliance.Componentize.DotNet.WitBindgen.0.1.0-dev.nupkg
The names and version seem to match up.
James Sturtevant (Jun 28 2024 at 21:15):do you have files in .\test\E2ETest\PackageTest\packages?
Joel Dice (Jun 28 2024 at 21:17):yes:
$ ls test/E2ETest/PackageTest/packages/
ByteCodeAlliance.Componentize.DotNet.Wasm.SDK.0.1.0-dev.nupkg ByteCodeAlliance.Componentize.DotNet.WitBindgen.0.1.0-dev.nupkg
packages should get created there by the e2e test: https://github.com/dicej/componentize-dotnet/blob/b040b2942f8eca9521020655ac68b21d6455db21/test/E2ETest/PackageTest/PackageTest.csproj#L34-L42 then the nuget.config should redirect to that folder
Joel Dice (Jun 28 2024 at 21:28):Ha, this fixed it:
diff --git a/test/E2ETest/testapps/nuget.config b/test/E2ETest/testapps/nuget.config
index b3330dd..288e808 100644
--- a/test/E2ETest/testapps/nuget.config
+++ b/test/E2ETest/testapps/nuget.config
@@ -1,7 +1,7 @@
<?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">
doh, will need to be carefule with casing of files too
Joel Dice (Jun 28 2024 at 21:38):Once we have CI coverage for at least Linux and Windows, this sort of thing will be caught automatically, so I'm not worried
James Sturtevant (Jun 28 2024 at 21:38):sounds like we are close!
Joel Dice (Jun 28 2024 at 23:23):Well, I managed to publish a couple of NuGet packages to my GitHub account and made them public: https://github.com/dicej?tab=packages . However, I don't think anybody can actually access them because the registry itself (https://nuget.pkg.github.com/dicej/index.json) requires authentication, and I can't figure out how to make it public. Does anyone have experience with this? Is there a better way to publish packages like this for a temporary fork?
James Sturtevant (Jun 28 2024 at 23:24):you could publish to https://learn.microsoft.com/en-us/nuget/nuget-org/nuget-org-faq#is-it-recommended-to-upload-my-test-packages-to-nuget-org
Last updated: Dec 13 2025 at 20:04 UTC