diff --git a/docs/workflow/README.md b/docs/workflow/README.md index 78b4fd3f19befd..881e578790c3af 100644 --- a/docs/workflow/README.md +++ b/docs/workflow/README.md @@ -17,6 +17,8 @@ The runtime repo can be worked with on Windows, Linux, macOS, and FreeBSD. Each platform has its own specific requirements to work properly, and not all architectures are supported for dev work. That said, the builds can target a wider range of platforms beyond the ones mentioned earlier. You can see it as there are always two platforms at play whenever you are working with builds in the runtime repo: +For WebAssembly-specific development workflows, see [WebAssembly Documentation](wasm-documentation.md). + - **The Build Platform:** This is the platform of the machine where you cloned the runtime repo and therefore where all your build tools are running on. The following table shows the OS and architecture combinations that we currently support, as well as links to each OS's requirements doc. If you are using WSL directly (i.e. not Docker), then follow the Linux requirements doc. | Chip | Windows | Linux | macOS | FreeBSD | diff --git a/docs/workflow/ci/failure-analysis.md b/docs/workflow/ci/failure-analysis.md index 2a9e7547ef5acc..59244617372564 100644 --- a/docs/workflow/ci/failure-analysis.md +++ b/docs/workflow/ci/failure-analysis.md @@ -127,7 +127,6 @@ The `Build Analysis` requests are sent to a queue. In certain scenarios, this qu While most failures can be matched via known issues, a few failures modes cannot be matched currently and it is valid to suppress them manually. Suggested wording to use in these situations (this list is not exhaustive): -- `/ba-g doc changes only` - Build analysis won't turn green for PRs that contain documentation .md file changes only. - `/ba-g deadletter` - Helix infrastructure failed with "This is a helix work item crash with status: DeadLetter." error message. Validate that the coverage provided by the dead-lettered leg is not relevant to the PR first. Rerun the leg instead if the coverage is relevant. - `/ba-g missing logs` - Logs are completely missing. - `/ba-g insufficient info in logs` - No good unique pattern in the logs to open a known issue. diff --git a/docs/workflow/debugging/libraries/debugging-vscode.md b/docs/workflow/debugging/libraries/debugging-vscode.md index c8f8f2424d3393..d6e21d35429c62 100644 --- a/docs/workflow/debugging/libraries/debugging-vscode.md +++ b/docs/workflow/debugging/libraries/debugging-vscode.md @@ -24,7 +24,7 @@ ## Debugging Libraries with Visual Studio Code running on Mono To debug the libraries on a "desktop" platform (Linux/Mac/Windows, not WebAssembly, or iOS or Android) running on Mono runtime, follow the instructions below. -See also [Android debugging](../mono/android-debugging.md) and [WebAssembly debugging](../mono/wasm-debugging.md) +See also [Android debugging](../mono/android-debugging.md) and [WebAssembly debugging](../mono/wasm-debugging.md). - Install the VS Code [Mono Debugger (`ms-vscode.mono-debug`)](https://marketplace.visualstudio.com/items?itemName=ms-vscode.mono-debug) extension - Create a `launch.json` file configuration with type `mono` diff --git a/docs/workflow/debugging/mono/wasm-debugging.md b/docs/workflow/debugging/mono/wasm-debugging.md index 26b5f62ec478b1..f6d29a2c176c7f 100644 --- a/docs/workflow/debugging/mono/wasm-debugging.md +++ b/docs/workflow/debugging/mono/wasm-debugging.md @@ -1,8 +1,192 @@ +# WebAssembly Debugging -WASM runtime debugging -====================== +This document provides debugging instructions for WebAssembly. -- Disable symbol stripping by setting the `WasmNativeStrip` msbuild property to `false`. See also, [collecting stack traces with symbols in Blazor](#collecting-stack-traces-with-symbols-in-blazor) +## Debug with VS Code +To debug WebAssembly with Visual Studio Code: + +### 1. Configuration + +Add the appropriate configuration to your `.vscode/launch.json` depending on your debugging scenario: + +**For WebAssembly applications, library tests, and general debugging:** +```json +{ + "name": "WASM Attach", + "request": "attach", + "type": "chrome", + "address": "localhost", + "port": +} +``` + +**For WASI applications:** +```json +{ + "name": "WASI Attach", + "type": "mono", + "request": "attach", + "address": "localhost", + "port": +} +``` + +Replace `` with the proxy port shown in your application's output. + +### 2. Setup Steps + +1. **Set initial breakpoint**: Place a breakpoint in `WasmTestRunner.cs` or your main entry point to prevent execution before you're ready +2. **Run the configuration**: Launch the VS Code debug configuration +3. **Set additional breakpoints**: Once stopped, set breakpoints in the code you want to debug +4. **Continue execution**: Click Resume or F5 to continue + +## Debug with Chrome DevTools + +### 1. Basic Setup + +1. **Open Chrome Inspector**: Navigate to `chrome://inspect/#devices` in a new Chrome tab +2. **Configure proxy**: Click "Configure": + +![image](https://user-images.githubusercontent.com/32700855/201867874-7f707eb1-e859-441c-8205-abb70a7a0d0b.png) + +and paste the address of proxy that was provided in the program output: + +![image](https://user-images.githubusercontent.com/32700855/201862487-df76a06c-b24d-41a0-bf06-6959bba59a58.png) + +3. **Select target**: New remote targets will be displayed, select the address you opened in the other tab by clicking `Inspect`: + +![image](https://user-images.githubusercontent.com/32700855/201863048-6a4fe20b-a215-435d-b594-47750fcb2872.png) + +### 2. Using DevTools + +1. **Sources tab**: A new window with Chrome DevTools will be opened. In the tab `sources` you should look for `file://` directory to browse source files +2. **Wait for files to load**: It may take time for all source files to appear. You cannot set breakpoints in Chrome DevTools before the files get loaded +3. **Set breakpoints**: Click on line numbers to set breakpoints +4. **Initial run strategy**: Consider using the first run to set an initial breakpoint in `WasmTestRunner.cs`, then restart the application. DevTools will stop on the previously set breakpoint and you will have time to set breakpoints in the libs you want to debug and click Resume + +### 3. For Native/C Code Debugging + +1. **Install DWARF extension**: Install the "C/C++ DevTools Support (DWARF)" Chrome extension +2. **Enable symbols**: Build with `WasmNativeDebugSymbols=true` and `WasmNativeStrip=false` +3. **Debug native code**: Step through C/C++ code, set breakpoints, and inspect WebAssembly linear memory + +## Starting Chrome with Remote Debugging + +To enable remote debugging for WebAssembly applications: + +```bash +# Close all Chrome instances first +chrome --remote-debugging-port=9222 +``` + +Replace `` with the URL shown in your application's output. + +## Common Debugging Workflow + +### For Library Tests + +For building libraries or testing them without debugging, read: +- [Building libraries](https://github.com/dotnet/runtime/blob/main/docs/workflow/building/libraries/README.md) +- [Testing libraries](https://github.com/dotnet/runtime/blob/main/docs/workflow/testing/libraries/testing.md) + +**Run the selected library tests with debugger support:** + +Run the selected library tests in the browser, e.g. `System.Collections.Concurrent.Tests` this way: +```bash +dotnet run -r browser-wasm -c Debug --project src/libraries/System.Collections/tests/System.Collections.Tests.csproj --debug --host browser -p:DebuggerSupport=true +``` + +Where we choose `browser-wasm` as the runtime and by setting `DebuggerSupport=true` we ensure that tests won't start execution before the debugger will get attached. In the output, among others you should see: + +``` +Debug proxy for chrome now listening on http://127.0.0.1:58346/. And expecting chrome at http://localhost:9222/ +App url: http://127.0.0.1:9000/index.html?arg=--debug&arg=--run&arg=WasmTestRunner.dll&arg=System.Collections.Concurrent.Tests.dll +``` + +The proxy's url/port will be used in the next step. + +You may need to close all Chrome instances. Then, start the browser with debugging mode enabled: + +```bash +chrome --remote-debugging-port=9222 +``` + +Now you can choose an IDE to start debugging. Remember that the tests wait only till the debugger gets attached. Once it does, they start running. You may want to set breakpoints first, before attaching the debugger, e.g. setting one in `src\libraries\Common\tests\WasmTestRunner\WasmTestRunner.cs` on the first line of `Main()` will prevent any test to be run before you get prepared. + +Use either Chrome DevTools or VS Code as described above to attach the debugger + +### For WASI Applications + +1. **Build with debug**: + ```bash + cd sample/console + make debug + ``` + +2. **Set up VS Code**: Use the Mono Debug extension configuration above +3. **Set breakpoints**: Place breakpoints in your Program.cs or other C# files +4. **Start debugging**: Launch the VS Code configuration + +## Troubleshooting + +### Files Not Loading in DevTools +- Wait patiently - source files can take time to load initially +- Try refreshing the DevTools window +- Ensure your build includes debug symbols + +### Breakpoints Not Hit +- Verify the proxy port matches your configuration +- Check that Chrome is started with remote debugging enabled +- Ensure your breakpoints are set in code that will actually execute + +### Connection Issues +- Verify no firewall is blocking the proxy port +- Check that the proxy is still running (visible in application output) +- Try restarting both the application and Chrome + +## Advanced Debugging + +### Enable Additional Logging + +Add environment variables for more detailed logging: + +```javascript +await dotnet + .withDiagnosticTracing(true) + .withConfig({ + environmentVariables: { + "MONO_LOG_LEVEL": "debug", + "MONO_LOG_MASK": "all" + } + }) + .run(); +``` + +### Native Stack Traces + +For native crashes with symbols: + +1. **Build configuration**: + ```xml + + true + false + + ``` + +2. **Install DWARF extension** in Chrome for C/C++ debugging support + +### Collect Stack Traces + +For detailed instructions on collecting stack traces and breaking into the JavaScript debugger from runtime code, see the [Native Runtime Debugging](#native-runtime-debugging) section below. + +## Native Runtime Debugging + +This section covers debugging the Mono WebAssembly runtime itself, native crashes, and advanced debugging scenarios. + +### Runtime Debugging Techniques + +- Disable symbol stripping by setting the `WasmNativeStrip` msbuild property to `false`. See also, [collecting stack traces with symbols in Blazor](#collecting-stack-traces-with-symbols-in-blazor) - Emscripten generates dwarf debug info and Chrome 80 and later can use it. @@ -56,7 +240,7 @@ corresponding wasm code: - The `wasm-dis` tool from `https://github.com/WebAssembly/binaryen` can be used to disassemble wasm executables (.wasm files). -# Deterministic execution +### Deterministic Execution Wasm execution can be made deterministic by passing the -s DETERMINISTIC=1 option to emcc. This will cause the app to always execute the same way, i.e. using the same memory @@ -88,7 +272,7 @@ which needs the same treatment. Running `make patch-deterministic` in `src/mono/wasm` will patch the emscripten installation in `src/mono/browser/emsdk` with these changes. -# Debugging signature mismatch errors +### Debugging Signature Mismatch Errors When v8 fails with `RuntimeError: function signature mismatch`, it means a function call was made to a function pointer with an incompatible signature, or to a NULL pointer. @@ -130,7 +314,7 @@ never meant to be reached, i.e. `no_gsharedvt_in_wrapper` or `no_llvmonly_interp These functions are used as placeholders for function pointers with different signatures, so if they do end up being called due to a bug, a signature mismatch error happens. -# Collecting stack traces with symbols in Blazor +### Collecting Stack Traces with Symbols in Blazor When debugging a native crash in a .NET 6 Blazor app or another WebAssembly framework that uses our default `dotnet.wasm`, the native stack frames will not @@ -258,10 +442,10 @@ dispatchGlobalEventToAllElements @ blazor.webassembly.js:1 onGlobalEvent @ blazor.webassembly.js:1 ``` -# Enabling additional logging in Blazor +### Enabling Additional Logging in Blazor In .NET 8+, Blazor startup can be controlled by setting the `autostart="false"` attribute on the -` ``` -## Blazor +#### Blazor In a `blazor` project, the script is `_framework/blazor.web.js` and it is loaded by `Components/App.razor` in the server-side project: @@ -341,3 +525,10 @@ Replace it with this (note that for a `blazor` project, `Blazor.start` needs an ``` + +## References + +- [Testing Libraries on WebAssembly](../testing/libraries/testing-wasm.md) +- [Debugging WebAssembly Libraries](../testing/libraries/debugging-wasm.md) +- [WASI Support](../../src/mono/wasi/README.md) +- [VS Code Debugging Guide](debugging/libraries/debugging-vscode.md) \ No newline at end of file diff --git a/docs/workflow/testing/libraries/debugging-wasm.md b/docs/workflow/testing/libraries/debugging-wasm.md deleted file mode 100644 index 8c7f4d2645ee6a..00000000000000 --- a/docs/workflow/testing/libraries/debugging-wasm.md +++ /dev/null @@ -1,57 +0,0 @@ -# Debugging libraries - -For building libraries or testing them without debugging, read: -- [Building libraries](https://github.com/dotnet/runtime/blob/main/docs/workflow/building/libraries/README.md), -- [Testing libraries](https://github.com/dotnet/runtime/blob/main/docs/workflow/testing/libraries/testing.md). - -## Run the tests with debugger support - -Run the selected library tests in the browser, e.g. `System.Collections.Concurrent.Tests` this way: -``` -dotnet run -r browser-wasm -c Debug --project src/libraries/System.Collections/tests/System.Collections.Tests.csproj --debug --host browser -p:DebuggerSupport=true -``` -where we choose `browser-wasm` as the runtime and by setting `DebuggerSupport=true` we ensure that tests won't start execution before the debugger will get attached. In the output, among others you should see: - -``` -Debug proxy for chrome now listening on http://127.0.0.1:58346/. And expecting chrome at http://localhost:9222/ -App url: http://127.0.0.1:9000/index.html?arg=--debug&arg=--run&arg=WasmTestRunner.dll&arg=System.Collections.Concurrent.Tests.dll -``` -The proxy's url/port will be used in the next step. - -You may need to close all Chrome instances. Then, start the browser with debugging mode enabled: - -`chrome --remote-debugging-port=9222 ` - -Now you can choose an IDE to start debugging. Remember that the tests wait only till the debugger gets attached. Once it does, they start running. You may want to set breakpoints first, before attaching the debugger, e.g. setting one in `src\libraries\Common\tests\WasmTestRunner\WasmTestRunner.cs` on the first line of `Main()` will prevent any test to be run before you get prepared. - -## Debug with Chrome DevTools -Open `chrome://inspect/#devices` in a new tab in the browser you started. Select `Configure`: - -![image](https://user-images.githubusercontent.com/32700855/201867874-7f707eb1-e859-441c-8205-abb70a7a0d0b.png) - -and paste the address of proxy that was provided in the program output. - -![image](https://user-images.githubusercontent.com/32700855/201862487-df76a06c-b24d-41a0-bf06-6959bba59a58.png) - -New remote targets will be displayed, select the address you opened in the other tab by clicking `Inspect`. - -![image](https://user-images.githubusercontent.com/32700855/201863048-6a4fe20b-a215-435d-b594-47750fcb2872.png) - -A new window with Chrome DevTools will be opened. In the tab `sources` you should look for `file://` directory. There you can browse through libraries file tree and open the source code. It can take some time to load the files. When the IDE is ready the tests will start running. You cannot set a breakpoints in Chrome DevTools before the files get loaded, so you might want to use the first run for setting the initial breakpoint in `WasmTestRunner.cs` and then rerun the app. DevTools will stop on the previously set breakpoint and you will have time to set breakpoints in the libs you want to debug and click Resume. - -## Debug with VS Code - -Add following configuration to your `.vscode/launch.json`: -``` - { - "name": "Libraries", - "request": "attach", - "type": "chrome", - "address": "localhost", - "port": - } -``` -Set at least one breakpoint in the libraries, you can do it initially in `WasmTestRunner.cs`. - -Run the configuration and be patient, it can take some time. Wait till VS Code will get stopped in `WasmTestRunner`. Set breakpoints in the libs you want to debug and click Resume. -![image](https://user-images.githubusercontent.com/32700855/201894003-fc5394ad-9848-4d07-a132-f687ecd17c50.png) diff --git a/docs/workflow/wasm-documentation.md b/docs/workflow/wasm-documentation.md new file mode 100644 index 00000000000000..0414feb91d0996 --- /dev/null +++ b/docs/workflow/wasm-documentation.md @@ -0,0 +1,136 @@ +# WebAssembly Documentation + +This document serves as a guide for contributors to the WebAssembly implementation in the dotnet/runtime repository. It provides links and references to technical documentation, workflows, and resources relevant to developing and maintaining WebAssembly support within this codebase. + +## Table of Contents + +- [Getting Started](#getting-started) +- [Building for WebAssembly](#building-for-webassembly) +- [Testing and Debugging](#testing-and-debugging) +- [Features and Configuration](#features-and-configuration) +- [Deployment and Hosting](#deployment-and-hosting) +- [Advanced Topics](#advanced-topics) +- [FAQ](#faq) +- [Contributing](#contributing) + +## Getting Started + +### What is .NET WebAssembly? +.NET WebAssembly allows you to run .NET applications in web browsers and other WebAssembly-compatible environments. The runtime uses the Mono runtime to execute .NET bytecode compiled to WebAssembly. + +### Supported Environments +- **Browser (browser-wasm)**: Run .NET applications in web browsers +- **WASI (wasi-wasm)**: Run .NET applications in WASI-compatible environments + +## Building for WebAssembly + +### Core Runtime Building +- **[Building CoreCLR for WebAssembly](building/coreclr/wasm.md)** - Build the CoreCLR runtime for WebAssembly targets +- **[Building Mono for Browser](../../src/mono/browser/README.md)** - Browser build guide with samples and troubleshooting + +### Libraries Building +- **[Building Libraries for WebAssembly](building/libraries/webassembly-instructions.md)** - Build .NET libraries for WebAssembly targets +- **[WebAssembly Build System](../../src/mono/browser/build/README.md)** - WasmApp.targets and build system internals + +### WASI Support +- **[WASI Support](../../src/mono/wasi/README.md)** - Experimental WASI support, building, and configuration + +## Testing and Debugging + +### Library Testing +- **[Testing Libraries on WebAssembly](testing/libraries/testing-wasm.md)** - Run library tests with different JavaScript engines and browsers +- **[Debugging WebAssembly Libraries](testing/libraries/debugging-wasm.md)** - Debug library tests in Chrome DevTools and VS Code + +### Runtime Debugging +- **[WebAssembly Debugging](debugging/mono/wasm-debugging.md)** - Consolidated debugging reference for WebAssembly applications and native runtime debugging +- **[VS Code Debugging](debugging/libraries/debugging-vscode.md)** - Set up VS Code for debugging WASM applications + +### Common Debugging Scenarios + +For debugging instructions including VS Code and Chrome DevTools setup, see the [WebAssembly Debugging Reference](debugging/mono/wasm-debugging.md). + +## Features and Configuration + +### Runtime Features +- **[WebAssembly Features](../../src/mono/wasm/features.md)** - Configure browser features, SIMD, threads, AOT, and more +- **[Threading Support](../../src/mono/wasm/threads.md)** - Multi-threading support and limitations + +### JavaScript Interop +- **[JSInterop in Wasm](https://learn.microsoft.com/en-us/aspnet/core/client-side/dotnet-interop/wasm-browser-app)** - JavaScript interoperability for WebAssembly applications + +### Globalization and ICU +- **[ICU for WebAssembly](../../design/features/globalization-icu-wasm.md)** - Globalization and ICU database configuration + +### Testing WebAssembly Changes +For testing WebAssembly implementation changes end-to-end, see the [testing documentation](../testing/mono/testing.md#testing-webassembly). + +## Advanced Topics + +### Performance and Optimization +- **[Profiling](../../src/mono/wasm/features.md#profiling-in-the-browser-dev-tools)**: Use browser dev tools profiler integration +- **[AOT Compilation](../../src/mono/wasm/features.md#aot)**: Improve runtime performance with ahead-of-time compilation +- **[IL Trimming](../../src/mono/wasm/features.md#trimming)**: Reduce application size by removing unused code + +### Samples and Examples +Located in `src/mono/sample/wasm/`: +- **browser-bench**: Performance benchmarking sample +- **browser-profile**: Profiling sample +- **console**: Console application samples + +### Workloads +- `wasm-tools`: Production WebAssembly tools and optimization +- `wasm-experimental`: Experimental features and templates + +## FAQ + +### How do I debug a library test failure seen on CI? + +See the [WebAssembly Debugging Reference](debugging/mono/wasm-debugging.md#common-debugging-workflow) for detailed instructions on debugging library tests locally. + +### How do I build for different WebAssembly targets? + +See the [Building for WebAssembly](#building-for-webassembly) section above for build instructions for different targets. + +### How do I test Wasm changes end to end? + +Use Wasm.Build.Tests or Wasi.Build.Tests. See the [Wasm.Build.Tests README](../../src/mono/wasm/Wasm.Build.Tests/README.md) for detailed instructions. + +### How do I enable multi-threading? + +See the [Threading Support](../../src/mono/wasm/threads.md) documentation for detailed multi-threading configuration and limitations. + +### What JavaScript engines are supported for testing? + +See the [Testing Libraries on WebAssembly](testing/libraries/testing-wasm.md#prerequisites) documentation for JavaScript engine installation and usage. + +### How do I collect native stack traces with symbols? + +See the [WebAssembly Debugging](debugging/mono/wasm-debugging.md#collecting-stack-traces-with-symbols-in-blazor) documentation for symbol configuration. + +### How do I run tests with different configurations? + +- **With AOT**: Add `/p:RunAOTCompilation=true` +- **With trimming**: Add `/p:EnableAggressiveTrimming=true` +- **Different JS engine**: Add `/p:JSEngine=SpiderMonkey` +- **Outer loop tests**: Add `/p:Outerloop=true` + +## Contributing + +### Code Style +- Runtime JavaScript code uses ESLint rules in `.eslintrc.js` +- Run `npm run lint` in `src/mono/browser/runtime` +- Install VS Code ESLint plugin for real-time checking + +### Building Changes +When making changes that affect native code or build configuration, see [Building the Repo](https://github.com/dotnet/runtime/tree/main/docs/workflow#building-the-repo) for detailed instructions. + +Then test your changes with [Testing the Repo](https://github.com/dotnet/runtime/tree/main/docs/workflow#testing-the-repo) using the relevant test suites. + +### Documentation Updates +When updating WebAssembly documentation: +1. Update this index if adding new documents +2. Ensure cross-references remain valid +3. Test documentation examples locally +4. Follow existing documentation patterns and styles + +For questions or additional help, see the main [workflow documentation](README.md) or ask in the dotnet/runtime repository discussions. \ No newline at end of file diff --git a/eng/pipelines/report-green.yml b/eng/pipelines/report-green.yml new file mode 100644 index 00000000000000..459098023013ea --- /dev/null +++ b/eng/pipelines/report-green.yml @@ -0,0 +1,41 @@ +# This CI job only runs on PRs where all other jobs are skipped. +# This allows Build Analysis to report green. Without this, no jobs would run, +# causing Build Analysis to hang indefinitely (or until someone commented "ba-g {justification}" on the PR). + +# Only run this on PRs +trigger: none +# Run for all branches, only on paths that no-op other jobs +pr: + autoCancel: true + branches: + include: + - '*' + paths: + include: + - docs/* + - '**/*.md' + - '**/*.txt' + - LICENSE.TXT + - THIRD-PARTY-NOTICES.TXT + - CODE-OF-CONDUCT.md + - CONTRIBUTING.md + - README.md + - SECURITY.md + - PATENTS.TXT + +# ABG - Always Be Green +jobs: +- template: /eng/common/templates/jobs/jobs.yml + parameters: + enableTelemetry: true + helixRepo: dotnet/runtime + jobs: + - job: Report_Green + enableSBOM: false + pool: + vmImage: ubuntu-22.04 + steps: + - powershell: | + Write-Host "This is a documentation-only change. Exiting successfully." + exit 0 + displayName: Exit 0 for doc-only changes \ No newline at end of file diff --git a/src/mono/browser/README.md b/src/mono/browser/README.md index baf2fe1785e678..af3ceeff317cf0 100644 --- a/src/mono/browser/README.md +++ b/src/mono/browser/README.md @@ -1,5 +1,7 @@ # Build WebAssembly +This document covers building .NET for WebAssembly in the browser. For WebAssembly documentation including testing, debugging, and deployment, see [WebAssembly Documentation](../../../docs/workflow/wasm-documentation.md). + If you haven't already done so, please read [this document](../../../docs/workflow/README.md#Build_Requirements) to understand the build requirements for your operating system. If you are specifically interested in building libraries for WebAssembly, read [Libraries WebAssembly](../../../docs/workflow/building/libraries/webassembly-instructions.md). Emscripten that is needed to build the project will be provisioned automatically, unless `EMSDK_PATH` variable is set or emscripten is already present in `src\mono\browser\emsdk` directory. ### Windows diff --git a/src/mono/wasi/README.md b/src/mono/wasi/README.md index 1c2f8a2dc01b71..915bade5917560 100644 --- a/src/mono/wasi/README.md +++ b/src/mono/wasi/README.md @@ -2,6 +2,8 @@ This directory contains a build configuration for WASI support, plus a basic sample. This is not intended for production use, nor is it currently supported. This is a step towards possible future support. +For WebAssembly documentation, see [WebAssembly Documentation](../../../docs/workflow/wasm-documentation.md). + ## Try it out Here is a quick overview of how to consume published artifacts. Assuming .NET SDK is already installed, you should run: @@ -112,26 +114,4 @@ Finally, you can build and run the sample: ### 4. Debug it -Also, you can build and debug the sample: - -``` -cd sample/console -make debug -``` - -Using Visual Studio code, add a breakpoint on Program.cs line 17. -Download the Mono Debug extension and configure a launch.json like this: -``` -{ - "version": "0.2.0", - "configurations": [ - { - "name": "Attach", - "type": "mono", - "request": "attach", - "address": "localhost", - "port": 64000 - } - ] -} -``` +For detailed WASI debugging instructions, see the [WebAssembly Debugging Reference](../../../docs/workflow/debugging/mono/wasm-debugging.md#for-wasi-applications). diff --git a/src/mono/wasm/features.md b/src/mono/wasm/features.md index 97f1e8213d988f..266bc1f50809f9 100644 --- a/src/mono/wasm/features.md +++ b/src/mono/wasm/features.md @@ -1,5 +1,7 @@ # Configuring and hosting .NET WebAssembly applications +For WebAssembly documentation including building, testing, and debugging, see [WebAssembly Documentation](../../../docs/workflow/wasm-documentation.md). + ## Table of contents - [Configuring browser features](#Configuring-browser-features) - [Project folder structure](#Project-folder-structure) diff --git a/src/mono/wasm/threads.md b/src/mono/wasm/threads.md index 6e73bfb0b575e6..cb73898c2c9307 100644 --- a/src/mono/wasm/threads.md +++ b/src/mono/wasm/threads.md @@ -1,6 +1,8 @@ -# Threaded runtime # +# Threaded runtime -## Building the runtime ## +For WebAssembly documentation including building, testing, and debugging, see [WebAssembly Documentation](../../../docs/workflow/wasm-documentation.md). + +## Building the runtime Build the runtime with `/p:WasmEnableThreads=true` to enable support for multi-threading.