Allow `custom_main.js` To Modify Command Line Switches

[AeonSake]

Currently, all proprietary command line switches are checked before the custom_main.js script can run, thus making it impossible to modify those specific switches.

Electron.NET/src/ElectronNET.Host/main.js

Lines 27 to 68 in 456135a

	if (app.commandLine.hasSwitch('manifest')) {
	manifestJsonFileName = app.commandLine.getSwitchValue('manifest');
	}
	console.log('Entry!!!: ');
	if (app.commandLine.hasSwitch('unpackedelectron')) {
	unpackedelectron = true;
	}
	else if (app.commandLine.hasSwitch('unpackeddotnet')) {
	unpackeddotnet = true;
	}
	else if (app.commandLine.hasSwitch('dotnetpacked')) {
	dotnetpacked = true;
	}
	if (app.commandLine.hasSwitch('electronforcedport')) {
	electronforcedport = app.commandLine.getSwitchValue('electronforcedport');
	}
	// Custom startup hook: look for custom_main.js and invoke its onStartup(host) if present.
	// If the hook returns false, abort Electron startup.
	try {
	const fs = require('fs');
	const customMainPath = path.join(__dirname, 'custom_main.js');
	if (fs.existsSync(customMainPath)) {
	const customMain = require(customMainPath);
	if (customMain && typeof customMain.onStartup === 'function') {
	const continueStartup = customMain.onStartup(globalThis);
	if (continueStartup === false) {
	////console.log('custom_main.js onStartup returned false. Exiting Electron host.');
	// Ensure the app terminates immediately before further initialization.
	// Use app.exit to allow Electron to perform its shutdown, fallback to process.exit.
	try { app.exit(0); } catch (err) { process.exit(0); }
	}
	} else {
	console.warn('custom_main.js found but no onStartup function exported.');
	}
	}
	} catch (err) {
	console.error('Error while executing custom_main.js:', err);
	}

It would be great, if the checks for the individual switches were moved below the custom_main.js handling, which would allow the script to potentially modify the command line switches. This change won't break any existing application but would allow users to, e.g., force a specific startup method (e.g., by also checking environment variables as shown in the wiki article).

On that note: there might be a better approach to force a startup method at compile-time, but this is currently the only realistic way to achieve this without requiring users to run the app with CLI arguments (or create shortcuts with CLI arguments), specifically .NET-first packaged execution.

[FlorianRappl]

Sounds good to me.

[softworkz]

On that note: there might be a better approach to force a startup method at compile-time, but this is currently the only realistic way to achieve this without requiring users to run the app with CLI arguments (or create shortcuts with CLI arguments), specifically .NET-first packaged execution.

I don't understand the motivation for this.

At this place, there is no way to make a change to the startup up method:

• If it is dotnet-first, then dotnet is running already - you cannot change it to Electron-first
• If it is electron-first, then dotnet still needs to be launched - you cannot change it to dotnet-first
• For packed vs. unpacked: This depends on the file layout on disk. You cannot change it here, and if the provided param for this would be wrong, then it's a bug, but not any choice you can make in a custom_main.js

[AeonSake]

You are absolutely correct. I fundamentally misunderstood how the interaction between electron and .NET works here. While my main use case for this is now not really relevant or practical anymore, I still think it's generally a good idea to let custom_main.js run before checking any of the arguments. Not that it makes much of a difference right now.

[softworkz]

You are absolutely correct. I fundamentally misunderstood how the interaction between electron and .NET works here. While my main use case for this is now not really relevant or practical anymore,

Nevermind - it's admittedly confusing as "unpacked" can refer to three things in our context:

• ASAR unpackaed >> The resources are not compressed in app.asar
• Unpacked output of elecron-builder (dotnet publish output) >> Built app on disk, just not packaged (final file layout)
• Electtron.NET unpackaged (dotnet build output) >> Used when debugging (different file layout)

I still think it's generally a good idea to let custom_main.js run before checking any of the arguments

Why?

[AeonSake]

Why?

Mainly from a maintenance standpoint. It makes sure, that whatever is added in the future, will also be done after custom_main.js is executed. At least I think it's less likely code is accidentally added before when all the switch logic is already after the script call. It doesn't matter for the current state though.

As for the reason I even started this whole discussion (and #1030 / #1003) is because I was trying to integrate velopack as a packaging/installer/updater provider which had some related limitations. This is mainly in regard to the main application entry point which is a bit tricky and not always obvious for Electron.NET (see electron-first vs .NET-first in unpackaged vs packaged). Makes it incredibly hard to work with it. I know this is not necessarily an issue with this project, just an observation from working with it. The built-in updater in electron is just absolutely garbage which lead me to this approach in the first place. However, with help from the velopack team for the exact install hook logic, I managed to get it now fully working with all the existing options of this project. I might still push a PR for #1003 specifically to have more customization options for the final app bundle (also stuff like how the .NET application shows up as sub-process in task manager, etc.).