The browser-wasm SDK should automatically reference the threading/perf-tracing ref assemblies

[lambdageek]

Some property property that uses the multithreaded runtime pack for the runtime artifacts and that adds a <PackageReference Include="Microsoft.NET.WebAssembly.Threading" IncludeAssets="compile" PrivateAssets="none" /> package to use the right ref assemblies.

And the same thing for the perftrace runtime pack and the System.Diagnostics.Tracing.WebAssembly.PerfTracing ref assemblies

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

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

Issue Details

---

Some property property that uses the multithreaded runtime pack for the runtime artifacts and that adds a <PackageReference Include="Microsoft.NET.WebAssembly.Threading" IncludeAssets="compile" PrivateAssets="none" /> package to use the right ref assemblies.

And the same thing for the perftrace runtime pack and the System.Diagnostics.Tracing.WebAssembly.PerfTracing ref assemblies

Author:	lambdageek
Assignees:	-
Labels:	arch-wasm, area-Build-mono
Milestone:	-

[lambdageek]

I think this is @radical 's #72815

[lewing]

it is #72412 but yes that is blocked on wbt at the moment

[radical]

The ref assemblies should be same for all the 3 variants, correct?

[lambdageek]

we have extra ref assemblies (Microsoft.NET.WebAssembly.Threading and System.Diagnostics.Tracing.WebAssembly.PerfTracing). Original plan was to place these in separate nugets that would get referenced when a user .csproj did some gesture. Does that make sense to do as part of the work you're doing?

I tried this out and it seemed to work (compilation would use the ref assemblies from the nugets, not the ones in the base SDK)

if we're doing different runtime packs, I'm not sure if it's possible to place ref assemblies into the runtime packs directly. that might be simpler.

[radical]

we have extra ref assemblies (Microsoft.NET.WebAssembly.Threading and System.Diagnostics.Tracing.WebAssembly.PerfTracing). Original plan was to place these in separate nugets that would get referenced when a user .csproj did some gesture. Does that make sense to do as part of the work you're doing?

So, we need 3 ref pack nugets then?

[radical]

We also need a few Wasm.Build.Tests to exercise using the threaded runtimes, and the extra ref assemblies.

[lambdageek]

we have extra ref assemblies (Microsoft.NET.WebAssembly.Threading and System.Diagnostics.Tracing.WebAssembly.PerfTracing). Original plan was to place these in separate nugets that would get referenced when a user .csproj did some gesture. Does that make sense to do as part of the work you're doing?

So, we need 3 ref pack nugets then?

No? we need the SDK to add a PackageReference to one of the two new nugets when the corresponding runtime variant is selected that just has the handful of updated ref assemblies.

[radical]

• What would be a good test to confirm that the correct runtime is being used?
• For the extra ref assemblies, I guess, we could use something from them

[lambdageek]

This is now mostly done (see https://github.com/lambdageek/hithread)

I think the only remaining thing is to automatically add a <PackageReference Include=Microsoft.NET.WebAssembly.Threading"/> that will pull in the threading-enabled reference assemblies which will quiet down the platform compatibility analyzer warnings about "unsupported" threading operations

https://github.com/lambdageek/hithread/blob/f7118d19ac88472576bd55671a33cfe9e5c2c099/hithread.csproj#L25

[lewing]

done