[PR #988] [MERGED] Core: Introduce cross-platform npm restore and check mismatch on publish #1399

Open
opened 2026-01-29 17:00:23 +00:00 by claunia · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/ElectronNET/Electron.NET/pull/988
Author: @softworkz
Created: 12/15/2025
Status: Merged
Merged: 12/17/2025
Merged by: @FlorianRappl

Base: developHead: submit_crossdebug


📝 Commits (4)

  • df8e269 Core: Introduce cross-platform npm restore and check mismatch on publish
  • 2d6d4e2 Fix up incorrect symlinks created by npm on Windows
  • 1d6ef7a ElectronProcessActive: Mark binaries as executable when debugging
  • 9d03787 ElectronProcessActive: Add check for platform mismatch

📊 Changes

2 files changed (+167 additions, -25 deletions)

View changed files

📝 src/ElectronNET.API/Runtime/Services/ElectronProcess/ElectronProcessActive.cs (+89 -6)
📝 src/ElectronNET/build/ElectronNET.LateImport.targets (+78 -19)

📄 Description

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.


🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/ElectronNET/Electron.NET/pull/988 **Author:** [@softworkz](https://github.com/softworkz) **Created:** 12/15/2025 **Status:** ✅ Merged **Merged:** 12/17/2025 **Merged by:** [@FlorianRappl](https://github.com/FlorianRappl) **Base:** `develop` ← **Head:** `submit_crossdebug` --- ### 📝 Commits (4) - [`df8e269`](https://github.com/ElectronNET/Electron.NET/commit/df8e269d5ce0a401a975b01fd11044d4f346230b) Core: Introduce cross-platform npm restore and check mismatch on publish - [`2d6d4e2`](https://github.com/ElectronNET/Electron.NET/commit/2d6d4e23208d3334249dd7d6d88876499417c63e) Fix up incorrect symlinks created by npm on Windows - [`1d6ef7a`](https://github.com/ElectronNET/Electron.NET/commit/1d6ef7a250d2542803a035007dc460ce653e2ef8) ElectronProcessActive: Mark binaries as executable when debugging - [`9d03787`](https://github.com/ElectronNET/Electron.NET/commit/9d0378798b6af1ba9bee9a9bc7c190f072b8c4bf) ElectronProcessActive: Add check for platform mismatch ### 📊 Changes **2 files changed** (+167 additions, -25 deletions) <details> <summary>View changed files</summary> 📝 `src/ElectronNET.API/Runtime/Services/ElectronProcess/ElectronProcessActive.cs` (+89 -6) 📝 `src/ElectronNET/build/ElectronNET.LateImport.targets` (+78 -19) </details> ### 📄 Description 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. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
claunia added the pull-request label 2026-01-29 17:00:23 +00:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/Electron.NET#1399