Core: Introduce cross-platform npm restore and check mismatch on publish

[softworkz]

This PR may seem contradictive at first sight.. :-)

It does this:

• Adds a build-time check when publishing that the package building is executed on the same OS which the packages are targeting
  This has caused user confusion because it can too easily be gotten wrong. Now it's no longer possible to build for OS A on OS B.
  One exception: Linux packages can be build on Windows (WSL)
• Introduces cross-platform behavior for npm install
  This means for example: When you are on Windows and osx-x64 is selected as RID, then the npm restore will do the restore as if it was on OSX.
• Automatically sets executable flag when running in unpackaged dotnet-first mode (= usually debugging)
• Adds a runtime check for mismatch between the RID for which the application has been built and the actual OS on which it's being run
  In case of mismatch, it exists with an appropriate error message
  (it would fail anyway, but without explanation otherwise)

So - why do x-platform npm restore first and then error out on platform mismatch when publishing?

It's all about debugging - remote debugging. And again, the fast way is of course without packaging - i.e. how debug is working now. For remote debugging, we need to have everything ready to work on the target/remote machine. For .net it's not a problem anyway, but the Electron executable is platform-dependent, This PR allows to get the right one, so that we can end up with a file set which runs on the target direct.ly, without any additional steps needed.

[github-actions]

pr-comment: Run #2

Tests 📝	Passed ✅	Failed ❌	Skipped ⏭️	Pending ⏳	Other ❓	Flaky 🍂	Duration ⏱️
1372	1210	0	0	0	162	0	2m 54s

🎉 All tests passed!

Github Test Reporter by CTRF 💚

🔄 This comment has been updated

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 8 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[FlorianRappl]

Great one !

[softworkz]

Great one !

I need a package

😍

[davidroth]

@softworkz The new ELECTRON100 check breaks my current build because I am publishing windows on linux(docker) via the electronuserland/builder:wine image. I have successfully used this approach for over five years, as it avoids the need for a Windows build machine in my CI/CD process.

Any reason for this strict check? I suggest adding an option to skip those checks. WDYT?

[softworkz]

Any reason for this strict check?

It is just meant to match reality: When the build process runs npm install on Linux, it doesn't install the Windows-specific
Electron binaries in node_modules.

I don't know much about WINE, but when it is able to properly emulate Windows, then the question would be why you are seeing this error at all, because then, MSBuild should not think it is running on Linux but on Windows instead. And then, the check should succeed.
Of course everything needs to be installed for WINE and be executed under WINE then, especially MSBuild and dotnet. Then it might work, but as said, I do not know enough about WINE to be sure.

[FlorianRappl]

Well, the OS is Linux - it's just that "all" (i.e., most) APIs are available (shimmed / proxied to use the POSIX equivalents).

Nevertheless, it's right that standard npm package installation would assume Linux, too, and use the respective binary. I am, however, not sure if that would lead to a problem. The electron-builder guide mentions this is a possibility, so it seems to work fine in general: https://www.electron.build/multi-platform-build.html

Maybe we can detect this case and allow it?

• Windows: Only Windows
• MacOS: Only MacOS
• Linux: Only Linux, except if Wine is detected; then allow Windows, too

Thoughts?

[softworkz]

Maybe we can detect this case and allow it?

• Windows: Only Windows
• MacOS: Only MacOS
• Linux: Only Linux, except if Wine is detected; then allow Windows, too

Thoughts?

The purpose of ELECTRON100 is not to prohibit something that is working, it's just about failing early with a proper explanation in cases where it's clear that the result will be broken (but without the user understanding the reason).

It's fine to add another exception - there is one already: Windows with WSL, building for Linux. There, the dotnet stuff is built on Windows and npm install as well as electron-builder are run on WSL. But it only works because the Electron.NET Core MSBuild logic is explicitly handling it that way.

@davidroth

When you say you have built Electron apps for Windows like this before - what exactly is "before"?

• Electron.NET Core - versions before ELECTRON100 has been added
• Electron.NET legacy only (electronize cli)
• Other electron apps only

[davidroth]

@davidroth

When you say you have built Electron apps for Windows like this before - what exactly is "before"?

• Electron.NET Core - versions before ELECTRON100 has been added
• Electron.NET legacy only (electronize cli)
• Other electron apps only

Actually, it’s neither.
We began using Electron.NET in 2019, but we were quickly frustrated by the development experience—specifically how Electron managed the .NET process—and encountered frequent instabilities with socket.io.

To solve these issues, we built a custom wrapper that replicated Electron.NET’s functionality but utilized a more robust architecture:

• SignalR Integration: We replaced socket.io with SignalR for more reliable communication.
• Reverse Startup Logic: We made .NET the root process that launches Electron. This enabled a seamless "F5" debugging experience directly within Visual Studio.

We used electron-builder via a Wine Docker image to generate Windows installers from a Linux environment.

While our custom solution served us well for years, it introduced a significant maintenance burden.
The arrival of Electron.Core is a major win for me because it mirrors our custom architecture but in a more polished, standard package. By migrating, I can strip out our proprietary glue code and focus entirely on the core project logic.

[softworkz]

Thanks for the clarification. I'm glad to see that the architectural changes in Electron.NET Core are so well-aligned with the needs and desires of other implementors. 😉

Back to the subject, I can only repeat the following:

I don't know much about WINE, but when it is able to properly emulate Windows, then the question would be why you are seeing this error at all, because then, MSBuild should not think it is running on Linux but on Windows instead. And then, the check should succeed.
Of course everything needs to be installed for WINE and be executed under WINE then, especially MSBuild and dotnet.

@FlorianRaappl

Well, the OS is Linux - it's just that "all" (i.e., most) APIs are available (shimmed / proxied to use the POSIX equivalents).

I said I don't know much about WINE, but I know enough to say that this is not an accurate description. WINE emulates a Windows environment by implementing a large range of Windows APIs, From that coverage, APIs having a POSIX equivalent are making a fraction at best, and even those few cannot be just shimmed but need adaption layers to provide Window-like functionality.
WINE implements things like COM, registry, Win32 GUI, multimedia APIs, Winsock, process model, PE loading and whatnot. It can run (older) MS Office, .net framework, WinForms, and many other things.
Based on that, I don't expect that dotnet publish (when the dotnet SDK for Windows is installed via WINE) would return "Linux" as the OS platform, because then, many of those Windows apps would not be able to run properly.
But I could be wrong - I don't know whether and how .NET SDK 8 or 10 is running under WINE.

@davidroth

I don't see how it would be a simplification of procedures to build Windows packages "from Linux" - you are not even doing that, but instead you are building this in a Docker container with WINE - that's not really "building from Linux" and requires you to maintain that Docker container properly to not only have the Electron requirements included, but also the .NET SDKs (which are probably not included in the Docker containers you referenced).

All-in-all, I would never even think about building like that. Nowadays it's so easy to get build machines running Windows, that your way only appears to me like an unnecessary complication than making anything easier.

That being said, you can try one of the Electron.NET Core packages from before the ELECTRON100 check has been introduced. If that would really work (which I doubt), then we can look into adding an exception for the check.
Otherwise, I would strongly recommend to build Windows packages on a Windows machine instead.

[FlorianRappl]

I'd say its an accurate enough description for our discussion. WINE is not its own Linux distribution so why should a Linux binary report Windows as an OS is foreign to me and not how the OS detection works at all.

If you run the Windows binary for dotnet the OS should be indicated as Windows. But then again this is irrelevant for the discussion (we can assume that the Linux binary is installed and that the OS detection will indicate Linux, still through WINE you will be able to execute Windows binaries - which is the effect the electron-builder is counting on).

Only thing that matters for the discussion is how to proceed. Anything else sounds like unnecessary clutter to me.

[softworkz]

WINE is not its own Linux distribution so why should a Linux binary report Windows as an OS

What I wrote is based on the assumption that the Docker image has the Windows versions of nodejs and npm installed which are executed under WINE.
If that's not the case then it's unclear to me how it's even working.