Follow-up on #32451
Follow-up on #80074
In #43651, the "Windows" OS name was lowercased to achieve target frameworks with RIDs in them. At that time, the original plan was to lowercase all TargetOS values but that had to be cut because of resources. This PR finishes that and updates build systems, YML, markdowns and managed components.
To not break existing developer workflows, the passed-in -os value is automatically lower-cased in the script entry points and validated in the msbuild entry point.
- Move all SetScriptCommands to a target, so they are placed after scenario in the generated script.
- Add WasmXHarnessArgsCli as an alternative variable that can be used from cli.
- Fix NodeJS symbolic links on Helix.
- Copy TestEchoMiddleware and RemoteLoopMiddleware even for Scenario=NodeJS.
- Enable System.Net.WebSockets.Client.Tests on NodeJS.
Since AOT'ing each test suite takes between 3-9 min, we need to shift the burden over to helix.
## This is done by:
1. building the test assemblies on the build machine
- the wasm part of the build is not executed on the build machine,
because it has the AOT build part
2. Zip up the test assembly+friends, *and* any bits required to run the wasm
app build for that on helix (eg. emsdk, wasm app targets, cross compiler etc)
3. Send all this to helix, and use a custom `aot-build.proj`
- which recreates all the build inputs for the `WasmBuildApp` target
using the paths for the assets on helix
- then we can run `WasmBuildApp` for the build, resulting in a wasm app
bundle.
4. Run the tests!
- We already have the bits required for building wasm apps on helix, supported
for `Wasm.Build.Tests`, which we can use here too.
## Trimming:
- Since, AOT can be so expensive, we use `EnableAggressiveTrimming=true`(EAT), but
that means that we could have issues due to trimming.
- And it can sometimes be unclear whether the build/test failures are due to trimming
or AOT.
- Because these builds+test runs are different from other builds, owing to the
"build partially on helix" step, a normal EAT build would not be the same as
- to help with testing this, we add two lanes to `runtime-staging`:
- `*_Mono_AOT`: builds AOT+EAT on helix
- `*_Mono_EAT`: builds EAT, on helix
- this is required because we want to run almost the same kinda
build: 1. build test assembly; *2. send to helix; 3. build wasm app;* 4. run tests
- This should effectively mean that we can see which errors might be due to EAT, and
which are clearly because of EAT+AOT.
Co-authored-by: Steve Pfister <steve.pfister@microsoft.com>
Co-authored-by: Marek Safar <marek.safar@gmail.com>
Co-authored-by: Mitchell Hwang <mitchell.hwang@microsoft.com>
Co-authored-by: Ankit Jain <radical@gmail.com>
* Add documentation on running tests using different Browsers other than chrome.
- XHARNESS_COMMAND="test-browser --browser=safari"
- Add ability to run against different browsers from the make file target `run-browser-tests` by adding `XHARNESS_BROWSER= ` to command line.
At the moment supported values are:
- `chrome`
- `safari`
- `firefox`
* Add gecko firefox requirements to testing docs.
Add a subset for compiling only the wasm runtime: `mono.wasmruntime`
This allows us to rebuild the wasm runtime without building the full libraries subset.
Updated documentation with new guidance.
Updated how we build the dotnet.timezones.blat.
* Trim trailing whitespaces
* Match raw with rendered
* Delete extra asterisks and |
* Update ELT Hooks - tail calls.md
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
I am not very familiar with Unix so I was not aware why I was having below error:
```
/home/jozky/runtime/.dotnet/sdk/5.0.100-preview.8.20362.3/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(379,5): error NETSDK1112: The runtime pack for Microsoft.NETCore.App.Runtime.browser-wasm was not downloaded. Try running a NuGet restore with the RuntimeIdentifier 'browser-wasm'. [/home/jozky/runtime/src/libraries/System.IO.FileSystem/tests/System.IO.FileSystem.Tests.csproj]
```
I tried running `dotnet restore --runtime browser-wasm` as suggested by the error but that didn't help.
The correct thing to do was to pass `Release` (with upper case R) to `Configuration` parameter.
cc @safern
Viktor Hofer
Marek Fišera
Pavel Savara
Kenneth Pouncey
Alexander Köplinger
Youssef VictorandJan Kotas
David Cantú
Aleksey Kliger (λgeek)
Maxim Lipnin