Problem

The current architecture spawns a new ModInstallerIPC.exe process for every mod installation, using error-prone socket/named pipe communication between Vortex and the .NET 9 server.

• The server implementation can be found here. It's installed as a node module upon running the installation script.
• The client implementation is an internal extension which is located here

Current flow:

1. Vortex client calls createIPC() to spawn ModInstallerIPC.exe
2. C# server listens on TCP socket or Windows named pipe
3. Messages serialized as JSON with custom UTF-8 protocol
4. Bidirectional communication via TestSupported, Install, Invoke, Reply commands
5. Process terminated after installation completes by the client.

Issues:

• Process spawning overhead for each installation
• Socket/pipe connection errors and timeouts
• Complex serialization/deserialization logic
• Callback management across process boundaries
• Resource cleanup complexity

Proposed Solutions

Option 1: Edge.js

Description: Direct in-process calls from Node.js to .NET assemblies without spawning processes.

Implementation:

• Convert ModInstallerIPC to a .NET library (DLL)
• Use electron-edge-js to load and call .NET methods directly
• Eliminate all IPC serialization code

Pros:

• No sockets/pipes needed
• Lower latency, minimal serialization
• Native Electron integration
• Moderate refactoring effort

Cons:

• Shares memory space - Vortex's memory is already stuck at 4GB due to V8 memory cage.
• We've used EdgeJS in the past but have moved away from it due to the old maintainer not supporting newer versions of Electron (it looks like a new maintainer picked it up though)

Option 2: Native Node Module (N-API)

Description: Build a native Node.js addon that hosts the .NET runtime using .NET Hosting APIs.

Implementation:

• Create N-API module in C++
• Use .NET hosting APIs to load and execute .NET assemblies
• Expose JavaScript API via N-API

Pros:

• Native performance
• Stable ABI (N-API)
• Works with .NET 9
• Clean TypeScript integration
• Full control over memory management
• Well established pattern used for most/all of Vortex's native modules

Cons:

• Significant development effort
• Complex build toolchain (node-gyp, CMake)
• Requires C++ and .NET hosting expertise
• Platform-specific builds

Resources:

• .NET Hosting APIs
• N-API Documentation

Option 3: gRPC

Description: Replace custom JSON protocol with industry-standard gRPC.

Implementation:

• Define .proto files for TestSupported, Install services
• Generate TypeScript and C# client/server code
• Replace socket handling with gRPC channels

Pros:

• Industry-standard protocol
• Strong typing with Protocol Buffers
• Better error handling
• Bidirectional streaming
• Less custom code

Cons:

• Still requires separate process
• Potentially more overhead than current solution but can run bespoke?

Option 4: WebAssembly (Blazor WASM)

Description: Compile .NET to WebAssembly and run in Electron renderer.

Pros:

• Modern approach
• Sandboxed by design
• Cross-platform

Cons:

• Limited file system access and may not be ideal for installers?