mono-nx Switch
More actions
| mono-nx | |
|---|---|
 | |
| General | |
| Author | exelix11 |
| Type | Developments |
| Version | 1 |
| License | MIT License |
| Last Updated | 2026/07/03 |
| Links | |
| Download | |
| Website | |
| Source | |
This is an unofficial port of the mono runtime to the Switch homebrew toolchain. It can run dotnet 9.0 applications using the mono interpreter by loading the dll or exe files directly on console. It can also build .NET assemblies as static libraries using mono AOT.
The mono-interpreter.zip release contains the mono interpreter, all the dotnet runtime libraries and the file .dll/.exe file association for hbmenu allowing you to copy .net dll programs to your Switch folder and running them directly. To build and use mono-nx, please follow the detailed step-by-step instructions provided in the GitHub repository.
What works:
- Common BCL classes such as
List,StringBuilderand so on. - P/Invoke, but only with libraries that were statically linked beforehand.
- Threads and async.
- Most of filesystem APIs.
- Sockets and http-only support for
HttpClient. - .NET wrappers for SDL2 and dear imgui which are included as static libraries.
- The interpreter seems rather stable even when running more complex programs, I did not test the AOT builds as much.
- Unit tests with XHarness (some dotnet repo tests are even passing!).
What does not work:
- HTTPS and most of
System.Securitydoesn't work because we have no openssl port on Switch. - Arbitrary P/Invoke doesn't work due to the lack of dynamic linking, all native function entrypoints must be defined beforehand and statically linked.
- Any other OS-dependant API that was not mentioned previously will likely not work because it was not explicitly implemented. Examples are
Console.Read,Console.Clear,Process,WinFormsand many more. - Also, exiting the interpreter and launching another dll or sometimes homebrew in the same hbmenu session will eventually crash. I'm not sure why this happens, historically mono has had problems cleaning up resources but it could also be an issue related to the homebrew environment. I tried to do some debugging but ultimately my workaround is to just terminate the process on exit.
Included demos:
- aot_example.nro is a fully self-contained AOT-complied C# application. It generates a random number and asks you to guess it.
- (*) pad_input.dll is a C# program that reads the controls with the native libnx api.
- (*) example.dll is a C# program that shows most of the APIs that are currently implemented.
- (*) explorer_demo.dll is a C# program that shows a file explorer-like GUI using imgui and SDL2. This will also work on windows and linux with no code changes if you use the author's cimgui fork.
- (*) guess_number.exe is the source from aot_example built with plain csc.exe on a windows vm to show off loading exe files as well. I'm not aware of any way to build this on linux so there's no build script for it.
(*) These will add the dll and exe file association to the hbmenu allowing you to launch them directly.
Changelog
v1
- This build fixes various stability issues, including one related to thread local storage that would crash mono at random.
- I'm also providing an "sdk build" of the toolchain, that is, the final binaries, header files and static libraries needed to build the interpreter without having to build the whole dotnet runtime on your own. To use the sdk zip extract it in the root of the repo, it contains all the correct paths where all the icu and mono artifacts should be. At this point you should be able to build
native/interpreterornative/aotdirectly. I don't expect this setup to survive libnx/gcc/portlibs updates via dkp-pacman so only use it with the monobuild docker container at the commit of this release, as of writing it is based ondevkitpro/devkita64:20260219.
v0
- First Release.