How to handle Electron Version selection in the future?

Question

How to handle Electron Version selection in the future?

Closed this issue a month ago · 26 comments

IMO, this is getting too complicated. It would be much easier and better when the adaption would happen dynamically during runtime - depending on the Electron version that is selected in the project properities.

Please see the discussion above and the examples I'm giving about how MS/Xamarin have been doing this for Android API changes for a long time already without shipping dozens of different versions.

I definitely understand this approach but was thinking to adopt Electron release approach thats why I was asking about incremental versions - in case there is a known bug for a specific release lets say for 36.0.0 then 36.0.1 would be released. While what you are proposing sounds great how complicated would it be to implement?

So for example lets say in version 37 a method takes an object of specific type as an input while in 38 it takes a string, is that easy to implement?
Some methods and events are added while others are dropped.

As for versioning already found my answer on Google - yes it is possible to publish lesser versions to Nuget.

Don't get me wrong what you proposing sounds like a proper sophisticated solution but is not something I am familiar with and would require considerably more time investment upfront than I can spare. I will leave it with you.

Originally posted by @agracio in #872

Answer 1 · 2025-09-03T00:03:33.000Z

I'm creating this new issue, because we've gotten quite a bit off-topic in the Taking it to the Next Level! issue.

Why do I think that a freely selectable Electron version is better?

(than having specific Electron.NET packages for each Electron version)

1. The approach has failed already

Because "having specific Electron.NET packages for each Electron version" - that is/was the current approach.

The decision to do so has surely been made for good reasons. And surely also in good faith, assuming to continuously publish new versions for new Electron versions. Eventually, this hasn't happened -. or rather ended at some point.
No matter why - it's open-source and free and there are no obligations to deliver any updates. As simple as that.

But unfortunately, in turn, the lack of updates has moved the project totally off-the-line.
As of now, it has completely disqualified itself for any kind of professional use.
It's future is uncertain, and even when there was a single update now, chances exist that it would stall once again afterwards.

2. Electron Updates are Security Relevant

A hard-coded version like 23.2.0 is another instant-disqualifying factor as well. You need to be able to use versions which have security fixes included.

3. API Changes?`

We have established already that Electron API changes are largely minimal and do not even bite most of the time.

Is this a solid reason to force users of Electron.NET onto a certain Electron version all the time until Electron.NET publishes a new version where those small API differences are addressed?

Think about - what would YOU want as a developer? Free version choice with a small risk that something breaks or being dependent on some open source developers finding the time to release a new version? (which might never happen at all)

4. API Versions

Another element has been forgotten a bit in this discussion as well: The primary reasons for changing or updating Electron are most of the time not the Electron features at all - but the features of the newer Chromium versions. That's why people want to update Electron most of the time, and that's why 23 is not an acceptable choice these days, even when don't need any newer Electron features.

Answer 2 · 2025-09-03T00:11:09.000Z

I am not saying that one solution is better than other and your idea does sound like it would be a great one with definitions loading dynamically, my point was that I am not ready to take on a such complex job hopefully owners can give you a hand.

That's what I've been alluding to in the other conversation, where you said you "completely disagree with the approach":

But this approach just accommodates for the fact that

the owners have no time
I have no time

for doing that many releases for each Electron version.
You can disagree as long as you want - but it's not gonna happen unless YOU do it or another volunteer comes around.
What I'm suggesting (how I've implemented it), is meant to give the project a future even without intensive work by me or by the owners.

Either that - or nothing - or YOU do it. That's the reality at the moment.

Answer 3 · 2025-09-03T00:19:48.000Z

I disagree about a couple of things:

Electron only supports 3 latest releases so assuming that there are security issues with Electron itself it needs to be upgraded.
If ElectronNET package for that release (example 36.0.0) has a security issue then an updated version 36.0.1 can be released.
API changes are minimal to a few methods/events between each major version but are very significant if we compare major versions that are far apart.
There is another reason to upgrade to newer Electron version - and that is support. As I mentioned earlier Electron only supports 3 latest releases, raising an issue for any other version gets an instant reply 'this version is no longer supported try to replicate this bug on supported version'

But this approach just accommodates for the fact that

the owners have no time

I have no time

This can be said about any repo - if it is not maintained it becomes obsolete.

You were proposing a different solution where depending on Electron version chosen different API would be loaded - if you have no time then who is going to develop this solution.

Answer 4 · 2025-09-03T00:19:54.000Z

While what you are proposing sounds great how complicated would it be to implement?

So for example lets say in version 37 a method takes an object of specific type as an input while in 38 it takes a string, is that easy to implement? Some methods and events are added while others are dropped.

Assuming you would volunteer to maintain this, I would get all things set up and give you instructions in a way that you'd only need to monitor the API diffs and implemented the changes according to the given patterns and instructions. And you can also ping me for help when in doubt.

So, when you really like to do it, you don't need to worry about the hard parts - I would get you there, that's no problem.

Answer 5 · 2025-09-03T00:21:45.000Z

Assuming you would volunteer to maintain this, I would get all things set up and give you instructions in a way that you'd only need to monitor the API diffs and implemented the changes according to the given patterns and instructions. And you can also ping me for help when in doubt.

But you would have to implement the initial API changes for a current Electron version 36, 37 or 38 and there are alot of them. Unless I misunderstood and you are proposing to not implement any API changes.

Answer 6 · 2025-09-03T00:24:01.000Z

But you would have to implement the initial API changes for a current Electron version 36, 37 or 38 and there are alot of them. Unless I misunderstood and you are proposing to not implement any API changes.

I would lay the groundwork that allows you to implement the API changes (similar to how Xamarin handles Android API changes).

Answer 7 · 2025-09-03T00:25:25.000Z

Could you elaborate with examples on how Xamarin handles changes, besides it still means maintaining each Electron release API changes just in a different way. After each change a new package needs to be published to Nuget.

Just finished my Electron 38 release so will look at this topic again tomorrow, good night 😴

Answer 8 · 2025-09-03T00:39:39.000Z

Here are some examples of what I'm talking about:

How it works on build

We (=I) create an Analyzer that is run on build (the user's build of their Electron.NET solution) and that is checking whether any APIs are used which are not available in the chosen Electron version.

That's basically how it works. Deprecations create a warning and hard incompatibilities create an error.

Answer 9 · 2025-09-03T00:42:26.000Z

I was just about to add another thing, both .NET and Node.js solutions need to implement API changes for each version of Electron.
API changes also have to apply to src\ElectronNET.Host\api\*.ts

Answer 10 · 2025-09-03T00:47:22.000Z

The above is the declarative side. For the implementation side, the recipes are:

New parameter added in new API version

We implement the parameter on both sides (C# and js). There are attributes for parameters as well.
An added param is down-compatible, because it will just be ignored at the js side

Parameter removed in new API version

We do nothing except add an attribute. Reason: see above

Entirely incompatible change

Different parameter type, different parameter order, totally diferent params, etc.

We add new methods, both on the C# and js side, with a name like:

apifunctiion37(param, param, etc.)

The new one gets decorated as available from 37 and the old one as available until 36.
This case is rare, but it can happen. MS/Xamarin to it the same way.

Answer 11 · 2025-09-03T00:53:37.000Z

Version Statics

In some cases, it might also be needed to adjust the bridging code (between C# and js) depending on the Electron version.

For those cases, we will also inject a global static variable (both, C# and js side) based on which you can vary the implementation when necessary.

Answer 12 · 2025-09-03T00:59:33.000Z

I am not following - let say we compare API of version 23 to 30, we find new methods, events also removed methods and events, changed method signatures etc. Those changes need to be implemented on both sides.

Next we compare 30 to 36 - again the same happens and we are talking about a significant amount of changes in both cases. When we moving from version to version those cases are not rare and are very common when jumping multiple versions. I just dont see how your approach of adding extra methods, extra decorations etc is better.

This very much looks like a nan approach that has code riddled with 'if/else' only in this case its new method names and pretty decorations instead of if/else but still will be a complete mess is we look across 15 versions from 23 to 38 and it will just keep growing with every new version.

Besides this approach still means that a new package needs to be published to Nuget with every new version of Electron so not sure what are the gains.

Answer 13 · 2025-09-03T01:09:09.000Z

I am not following - let say we compare API of version 23 to 30, we find new methods, events also removed methods and events

You need to go version by version.

23 to 24
24 to 25
25 to 26
etc.

Besides this approach still means that a new package needs to be published to Nuget with every new version of Electron so not sure what are the gains.

The gain is that when no new package is published, you can still update to a newer Electron without being restricted to the latest version that Electron.NET is supporting.
You have the risk of incompatibility, but you can look up the changes or just try out whether you're affected.
Generally, it's pretty unlikely that you are affected and that allows you to update to a newer Electron without depending on Electron.NET. And when there's an API change that bites you, you can still submit a PR to Electron.NET to get it fixed.

That's the gain - and it's huge.

Currently: Forced to 23.2
Future: Never locked anymore

Answer 14 · 2025-09-03T01:13:31.000Z

And even when Electron.NET would be entirely dead and wouldn't merge your PR - you can still use ElectronHostHook for implementing a new or changed API yourself and use that instead of the shipped and incompatible one.

Answer 15 · 2025-09-03T01:16:49.000Z

Besides this approach still means that a new package needs to be published to Nuget with every new version of Electron so not sure what are the gains.

Users will always use the latest version of the Electron.,NET package, no matter which Electron version they are using..

This means that in case when a bug is discovered, we don't need to ship updates for 10 packages but just for a single one.

Answer 16 · 2025-09-03T01:30:47.000Z

First I would not consider supporting Electron versions that are 'out of support' - that is the reason I am talking about versions 36 - 38.
As for Electron version lock it can be moved to .manifest file along with electron-builder version.

And even when Electron.NET would be entirely dead and wouldn't merge your PR - you can still use ElectronHostHook for implementing a new or changed API yourself and use that instead of the shipped and incompatible one.

Well when was the last time you heard anything from repo owners, I have a feeling we might be already having this discussion just between ourselves. 🤔

Answer 17 · 2025-09-03T01:31:03.000Z

This very much looks like a nan approach that has code riddled with 'if/else' only in this case its new method names and pretty decorations instead of if/else but still will be a complete mess is we look across 15 versions from 23 to 38 and it will just keep growing with every new version.

That these things are growing is just natural. But it doesn't need to be growing infinitely. At some point we may determine that we change the minimum supported Electron version from23 to 30 (example) and when doing so, we can drop all stuff and conditions about earlier versions.

only in this case its new method names and pretty decorations instead of if/else

It's way more than that. Not only does that allow us to always ship just a single version on updates, it also brings additional benefits:

When compiling, you automatically get a kind of "compatibility report" through the analyzers which run during build
So, you can change the Electron version and just need to recompile to see whether you're good to update or whether there are any blocking issues that you need to resolve

Answer 18 · 2025-09-03T01:37:13.000Z

First I would not consider supporting Electron versions that are 'out of support' - that is the reason I am talking about versions 36 - 38.

Sure. It doesn't need to start from 23. But there needs to be a minimum version from which on all major-changes are implemented, going forward.

As for Electron version lock it can be moved to .manifest file along with electron-builder version.

Which lock? Theres a selection in the project properties which gets propagated everywhere where needed.

Well when was the last time you heard anything from repo owners, I have a feeling we might be already having this discussion just between ourselves. 🤔

They have always responded so far. My first post today was at night-time already, so what do you expect? I'm sure they'll respond within the next few days.

Answer 19 · 2025-09-03T01:49:00.000Z

Electron version is defined in package.json which is copied from resources on 'start' (StartElectronCommand.cs, Actions/DeployEmbeddedElectronFiles.cs) as well as hardcoded in BuildCommnd.cs file which is triggered on 'build'. Both can be moved to manifest file.

Anyway it is getting really late, as I said before I am not on board with decorations, multiple methods in .NET and Node.js code as well as globals to send to Node.js for conditional execution so best of luck.

Answer 20 · 2025-09-03T01:55:52.000Z

Electron version is defined in package.json which is copied from resources on 'start' (StartElectronCommand.cs, Actions/DeployEmbeddedElectronFiles.cs) as well as hardcoded in BuildCommnd.cs file which is triggered on 'build

Ok, got it, you haven't even read through the other conversation - sigh..

am not on board with decorations, multiple methods in .NET and Node.js code as well as globals to send to Node.js for conditional execution, so best of luck.

I'm not going to do that, I just suggested that as a possible way if you want to engage.

I made the changes described in the other topic as a necessity for making use of Electron.NET in our own project. Specifically, I needed to be able to start into debugging quickly and to debug Linux versions on WSL from Visual Studio.
I found the results a bit too cool to keep them private and I think this project has deserved another chance, so I'm offering to upstream those changes back to the project - if the owners want to have it.

That's all of the story. It doesn't need to happen if they don't want it. I'm also not much concerned about Electron APIs because we have a much more sophisticated way for inside-outside communication between JS and C# through a universal projection mechanism (including events, property set/get, async and sync invocation) which works not only with Electron but on Windows, Android, Xbox, Tizen, iOS etc.
Electron is just a small piece of the puzzle. I'll gladly share my work - as is. I don't care whether anybody agrees or disagrees or wants something different.

That's what's on the table and no discussion will change it.

I'm the one who has something to offer that has value and substance - while others are just talking.

Answer 21 · 2025-09-03T02:11:23.000Z

Just realised that my suggestion would not work either, .NET API is published in ElectronNET.API nuget while Node.js API is published in ElectronNET.CLI nuget.

Your idea is not going to work either since developers rarely bother to update dotnet tools, they can be struck even on current version trying to use new ElectronNET.API.

Both should be in ElectronNET.API with Node.js part bundled as an asset instead of embedded resource and copied to a correct folder during nuget install.

Answer 22 · 2025-09-03T02:13:55.000Z

You idea is not going to work either since developers rarely bother to update dotnet tools, they can be struck even on current version trying to use new ElectronNET.API.

Idea????

Damn! Go and read through #872

Everything described is DONE AND WORKING!

(there is no .net tool anymore)

Answer 23 · 2025-09-03T02:27:37.000Z

Right so if I was to use Electron 38 with your solution and would need to call an event or method that is not implemented in .NET API it would totally work.
Anyway this conversation is not going anywhere, looks like its better for me to stay away from this project.

Answer 24 · 2025-09-03T02:32:27.000Z

so if I was to use Electron 38 with your solution and would need to call an event or method that is not implemented in .NET API it would totally work.

Even that question I've already answered: #891 (comment)

Not that it would be a great solution at all - but you DO HAVE options. Right now, you don't.

looks like its better for me to stay away from this project.

It very much depends on whether you REALLY want to get on board and work on the project or whether you just want to dictate your desired direction while just pretending interest in contributing...

(which - btw - appears to be one of the core reasons why the owners lost interest in the project...)

Answer 25 · 2025-10-09T21:29:41.000Z

Just to introduce my take: The reason I cannot contribute is that I am just overwhelmed with other work. In general I am giving prio to projects that seem to be needed - the need being transferred by people / orgs actually putting money in. Electron.NET does not seem to be needed on that level. Everyone is happy with the current state. There are not donations and with exception of a few people no one interested in contributing time-wise.

As for the issue: I am a huge fan of having the electron version selecteable. It was one of the first things I proposed to Gregor - I'd love to have an internal re-design with an adapter pattern; being able to separate between used Electron version and the Electron.NET version. But then again, Gregor had doubts of the benefits and without enough interest I could not justify spending time on it. C'est la vie.

Thanks for the discussion and for all the work / contribution efforts @softworkz - I do actually appreciate that.

Answer 26 · 2025-10-09T22:40:27.000Z

Just to introduce my take: The reason I cannot contribute is that I am just overwhelmed with other work. In general I am giving prio to projects that seem to be needed

Fully understandable. From my side, I can be even more direct by saying that I'm prioritizing paid work. I'm contributing to other projects when there's either a mutual benefit, i.e. an exchange, or something is so valuable that that it just fair to give something in return for the gained benefits.

I am a huge fan of having the electron version selecteable. It was one of the first things I proposed to Gregor - I'd love to have an internal re-design with an adapter pattern; being able to separate between used Electron version and the Electron.NET version. But then again, Gregor had doubts of the benefits

To be honest, I cannot follow that kind of reasoning:

Being forced to an ancient Electron version is a direct K.O. => you walk away and look for something else
A potential API incompatibility is not a big deal:
- You can fix it - or
- Switch back to an earlier Electron version

Fixing it might take a few hours at max - and switching back to an earlier version takes just a few minutes!!

So I do not understand what kind of "bad thing" we would want to "protect" users from? (by not allowing them to switch)

And on top of that - we don't know whether such incompatibility even exists!

I'm currently on Elecron 37.5.1 and Electron builder 26.0.15. I haven't encountered the slightest issue...

It's a phantom discussion, actually.

Why do I think that a freely selectable Electron version is better?

1. The approach has failed already

2. Electron Updates are Security Relevant

3. API Changes?`

4. API Versions

“Introduced in API X” annotations

Deprecations mapped to .NET [Obsolete]

Platform/version awareness via [SupportedOSPlatform]

How it works on build

New parameter added in new API version

Parameter removed in new API version

Entirely incompatible change

Version Statics