mirror of
https://github.com/ElectronNET/Electron.NET.git
synced 2026-02-03 21:25:13 +00:00
Taking it to the Next Level! #968
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @softworkz on GitHub (Feb 22, 2025).
Hi @FlorianRappl and @GregorBiswanger,
after reading the "Reloaded Discussion", I thought it's time for some positive vibe and try to move things forward a bit.
Before I'm going to shock you with the intentions and ideas I have, I think I should drop the magic words, saying that I'm willing to actively help in these regards rather than demanding anything. Essentially, I'm kind of forced into it, because the slow debugging startup times (and a few other limitations) are preventing me from finishing my work. Now I could do just the minimum required changes privately, but I thought it would be nice and fair to provide some return for the benefits that we gain from your project.
Proposed Changes
In the other conversation, you mentioned that you made some plans for future evolvement, so I hope this is not too far off, even though it may appear a bit radical ☢
Anway, here's what I'm up to:
Ideally also get it working like with Browser Link
This means to use a regular build (to MSIL, without publish) at the .NET side and an unpackaged configuration at the Electron side (just npm install, not invoking electron-builder)
Putting the electron files into the same subfolder path like the .net build output, e.g.
bin\net8.0\win-x64, becausebin\Desktopis ambiguous when building for multiple target RIDs.Only the electron build commands need to be run on WSL, the .net side can be built on Windows
Let me know what you think about it!
sw
@softworkz commented on GitHub (Feb 22, 2025):
I'm not coming empty-handed...:
@FlorianRappl commented on GitHub (Feb 22, 2025):
Yeah that sounds super awesome and goes in the direction (but honestly already quite a lot further) what I had originally in mind.
So you definitely have my blessing!
@softworkz commented on GitHub (Feb 22, 2025):
How about setting up a new branch for this, like nextgen or so?
My typical approach for such things is to "race" over all the tough points to get to a point where I got it roughly working - at least enough for me to know that it's doable. That phase is already done, so we're not talking just about ideas, but most of the core points are already confrimed and kind-of working.
I could create a PR against a new branch, to allow you guys and everybody else to try it out, and check out the details.
I'll follow-up with a few posts, showing what I got working already and how, so that we can discuss things rather than me just dictating the result.
Sounds good?
@GregorBiswanger commented on GitHub (Feb 23, 2025):
At first glance, I really like it too!
It would be exciting to see if everything works when it's in use...
@softworkz commented on GitHub (Feb 23, 2025):
I'm starting a series of posts, documenting and explaining the changes I've made so far, Let's start with this:
.NET Project System Extension & Manifest Replacement
In the screenshot above you can see an "Electron.NET" section. This is made possible through extensibility of the .NET/VS project system. It is working without the need for developing a Visual Studio extension like in case of the older project system. It is working working through the nuget package. So that part doesn't change: You add the Electron.NET nuget package to an ASP.Net Core project just like usual. There's also no requirement to use Visual Studio, but if you do, you get this nice UI tab in the project designer as shown above.
Changes made there, go directly into the .csproj file:
That's essentially the same plus a little bit more than what is currently in
electron.manifest.json. The motivations for this change are:electron.manifest.json)electron.manifest.json)The very first building block now, is to automatically generate a package.json file (for the Electron app) at design time.
This is done by MSBuild targets which are run as part of the design-time builds.
The package.json file is generated under
/obj/<Configuration>/<runtime>/<rid>/package.json.Here you can see it being updated automatically while editing the values in the app designer:
https://github.com/user-attachments/assets/f3855553-e734-4419-8075-47334639af9a
@softworkz commented on GitHub (Feb 23, 2025):
Building
Prerequisites
RID-Specific Builds
Since we always end up having RID-specific output, we can do so right away, even when not publishing. This allows pinpointing platform-specific issues early (like unsupported APIs), but most importantly, it allows a clean separation of outputs, because the RID gets included in the output paths when specificed (this happens automatically by the build system).
To make this more explicit, I've added a selection - which also enforces that one is specified (if not using VS, there's still one set as default).
Now we get output paths like this:
bin\Debug\net8.0\win-x64\This allows to have a separate Windows and a Linux output (like for running on WSL) without conflicting.
Unpackaged App Layout
For running and debugging, we also need the Electron part. This is platform-specific as well (at least when using Electron), so this part should go together with the output under the same folder.
For simplicity and avoiding ambiguities, I'm using a dotted subfolder at the moment:
.electronSo, the full output tree looks like this:
Populating the
.electronfolderNext, we need to fill the content of the
.electronfolder. This is not much different (with regards to the result) as currently, except the following:The files in the folders (api, ElectronHostHook, splashscreen, .vscode) are included in the .nuget as plain files
This allows letting MSBuild handle copying and change detection. Even though these never change, it needs still be determined whether they need to be copied or whether all files are there already - that would be difficult when extracting them from embedded resource like it's done currently
While the icons are only needed when packaging, the splash screen image is needed for unpackaged builds as well.
As seen above, the path of the splash screen image gets stripped when creating the
package.jsonfile. This is because it is always copied into the.electronfolder, no matter where it is - which avoids the current path problems.=> it could also be put into a predetermined subfolder of course
This generated file (see above) needs to be copied to the .electron folder as well
After building, the
.electronfolder will look like this:Build Targets
MSBuild is a creature of its own and its inner workings not directly obvious at first sight, and even worse when trying to figure out how to do certain things in the right way. But luckily I had to jump over this hurdle before and what we need here is not a big thing. I've added comments in the files which should allow to follow what's happening. The following targets are defined for building (I'll get to the publishing part later on).
What helps to understand a bit better is this: In MSBuild, there's almost always a separation between "planning" and "execution" when it's about processing files and generating output.
Practically speaking: Before any actual compilation of file-copying is performed there many targets/tasks being executed for the sole purpose of collecting and calculating all the input and output files before something is done.
This provides the benefit of building incrementally: only doing what's needed without repeating anything that has been done already and is still valid. And we're leveraging this for the Electron side as well.
The following targets are defined for it:
This is a helper target which sets properties for the Electorn-specific paths. It needs to be in a target so that it can be executed at a point in time when the base properties it is relying on are properly set
This runs during build but also in design-time builds. Currently, it does the following:
package.jsontemplate with actual values from the projectpackage.json(underobj/xxx/xxx/xxx/package.json)=> This is IMPORTANT, as it allows to avoid running
npmwhen there's no changeElectronFilesand sets the target path for each item. The group includes:This is executed later (after the
CopyFilesToOutputDirectorytarget), and only during actual builds.It specifies the
ElectronFilesitems as inputs and their target paths as outputs. This has the effect that the target will be executed only when any of the source files is never thant its target counterpart. This gives us the "only build when necessary" effect. It does the following:npm installin the.electronfolder (build output)This runs during a clean or a rebuild. All it does is adding the files in the
.electronfolder to the Clean item group, so that they'll get properly removed when cleaningThat's all for building. (we'll get to publishing later)
@softworkz commented on GitHub (Feb 23, 2025):
Incremental Build Demo
Note that "Building Electron" here means to copy (update) the changed files and run
npm installin the.electronfolder.https://github.com/user-attachments/assets/a16e097c-5958-4fe9-99ed-c7b9355ad4a2
@GregorBiswanger commented on GitHub (Feb 23, 2025):
One challenge I see here, which is why I didn't make it freely selectable by design in the past. For example, there are many breaking changes between the native Electron versions.
Events are called something different, functions have been removed, different data structures, etc.
The same applies to Electron builds, too. This is then only compatible with certain native Electron versions.
It would be interesting to know how you can stabilize this here?
@GregorBiswanger commented on GitHub (Feb 23, 2025):
For support native Electron extensions, we have integrated a feature, called Electron Hooks, typically require an Electron CLI again. This is because it manages triggering actions like "npm install," starting TypeScript, etc.
However, this might also work via MSBuild?!
@softworkz commented on GitHub (Feb 24, 2025):
Yes, I've seen your earlier comments in this direction. Yet I've seen that people are using more recent Electron versions with ElectronNet and there's currently 30.0.3 in the devlop branch vs. 23.2.0 in the main branch, plus an open PR for switching to 31.
This makes me assume that these newer Electron versions are at least partially tested by users.
I also have the suspicion that the stability of the Electron APIs has improved in the more recent history (= since 23). Last year I had updated an older (non-.net) Electron app of ours without any issues even though it's using quite a number of Electron APIs.
Currently in Electron.NET, it's hard to change the preconfigured version. Of course this has the advantage of keeping everybody on the safe side, but it has also prevented most users from trying different versions, so there's little to no feedback about compatibility with newer versions except those PRs to the develop branch.
My thought is that allowing to switch the version freely will bring more feedback and possibly also PRs from users with appropriate fixes. Since there's UI now to switch the version, it would also be possible to show a warning ("unsupported/untested") when selecting any other version than 23.x.x - until others are confirmed working.
Generally, I see two approaches for this:
Writing Integration Tests
Other than unit tests (which might not help much for this), integration tests would mean to create a test app and run coded tests for the various APIs in the context of the running app.
The whole thing could then be run with at least all the major Electron versions since 23.
AI assistance could be used for avoiding to code all the tests by hand.
Autogeneration of Electron API Projection
This would be a bit more advanced, but I've done something very similar before. Electron.NET is just a small puzzle piece for us for covering Linux platforms. We have a kind of cross-platform meta-framework which allows us to bring the same app to many platforms. It works on top of various other frameworks, namely WinUI3, UWP (xbox), MAUI and Electron.NET (plus generic web), using always the same html/js core code but extended by many platform-specific features done in C# (a shared base, plus platform-specific C# with P/Invoke etc. and a range of plugins).
The core of interaction is a messaging-based remoting which works in both directions:
The "native" (C#) side can expose objects to the JS side in the browser. This causes the creation of proxy objects inside the browser engine which have the same methods, properties and events(!) like the C# object. Method invocation can be synchronous or async. For subscribing to C# events, there's a special method provided. Essentially, you can transparently work with C# objects almost (few caveats only) as if they were JS objects.
For the other direction, it works a bit different. Since C# is a type language, the typings need to exist in advance. There's a helper JS module which you can give a list of JS modules. It then retrieves or instantiates their exports and generates C# interfaces for those. As it cannot know the return types and parameter types, those are of type object, but well - that's how JS works.
At runtime, when the C# side needs to work with a JS object, the framework is creating C# proxy objects implementing those generated interfaces. It also works for subscribing to events from JS objects (event emitters). It's probably the most comprehensive JS-C# interaction framework that exists (last time I looked around).
Just that you know about the background of where I'm coming from. So, a similar autogeneration would also be possible here. Since TypeScrip declarations are available for Electron, this also wouldn't need to end up having object as parameter and return types. Once it's auto-generated, you can easily generate this for every major Electron version.
But I'm not sure whether I got that much time to spend, so probably aim for a simpler solution first. :-)
@softworkz commented on GitHub (Feb 24, 2025):
I haven't forgotten that part, but here I'm not sure yet about the way. I see these two options:
ElectronHostHookcontents to the.electron/ElectronHostHookoutput foldernpm installandnpx tscthereor
I haven't tried this yet, but the idea would be to
./to./ElectronHostHook.electron/ElectronHostHookfolderI'll look into feasibility of the second approach, when it doesn't work nicely, the former approach should always do it.
Either way it's clear this this should work just like before.
@softworkz commented on GitHub (Feb 24, 2025):
ElectronHostHook
That part was a bit mind-bending to figure it out. Not about how to handle it but rather about understanding the way how it's done and how it rather should be done, because the current approach is - err - not quite by the books.
The
ElectronHostHookpart is currently treated like a separate application, means it has its own dependencies and a separate package restore (npm install) is run for it - which makes it two separate and independent things. But then - at runtime - it gets loaded by main.js as if it were part of the main nodejs app - even though it has its own node_modules and it might not even be compatible in its dependencies.Now I understand that this was also done in order to perform TypeScript compilation of a custom
ElectronHostHookfolder. But that's not really necessary in ASP.NET Core projects. TypeScript compilation happens automatically (maybe it has been different in earlier days).The Solution
Okay - so what we need is just a single npm install as it's all a single node.js application. But the
ElectronHostHookimplementation can still use dependencies that are not included in the main Electron app - what to do? Merge the dependencies fromElectronHostHookinto the package.json of the main app? But there might be conflicts or duplications, that doesn't sound solid either.This is what took me some time, albeit the solution is pretty simple: We need to treat ElectronHostHook just like another dependency of the Electron node.js app.
And that's what it already is: it has its package.json and a number of compiled js files. Now we need to add it as a dependency in the package.json of the Electron app. Like this:
When we run
npm installnow, the host hook "package" gets installed undernode_modules/electron-host-hook- just like any other package. And npm also reads the dependencies from that package.json file - this means for example, when the host hook code has exceljs as a dependency then it gets installed as well.In turn, we are creating a correct app config and we need to run
npm installjust once - not twice.The best part: nobody with a custom host hook will need to change anything.
Additional Notes
Electron Types in HostHook
index.ts and connector.ts are currently using Electron.App in their constructors. This is not valid because the host hook package.json doesn't import Electron as a dependency. And I don't think it should, because this would just blow up everything and it's purely a design-time thing - the generated js files don't have typing anyway.
Hence I would just change Electron.App to Any and it's all good (and users won't be confronted with those errors anymore.
(in the development solution it doesn't error because it is imported elsewhere and Intellisense adds all dependencies to a common pool, but for Electron.NET consumers, these errors do show up - have seen it as well)
Package Diet
All generated packages will become 30 MB smaller in size.
That's because all packages currently are including the TypeScript dev dependency package which isn't actually needed:
@softworkz commented on GitHub (Feb 25, 2025):
Host Hook is all good now. I've changed the first post into a task list for tracking progress. Next point is:
Debugging
I belive this is a point where many interested developers have turned around, looking for other possible options. The current behavior is indeed somewhat hard to sell: normally in ASP.NET projects, you can easily work and debug the project, but when they come to try Electron.NET and start debugging, they realize that debugging doesn't work as expected. Instead of debugging their code, the debugger is debugging an Electron process where there's nothing interesting to see with a managed code debugger: There just isn't any managed code running in Electron/Chromium processes.
And then - well, you can of course attach to the ASP.NET process (with the new "Re-attach to process" feature in VS, this has become a bit less tedious) or you can add
Debugger.Launch()to your C# code - still this is slowing down development.But the worst point here, is that when the debugger doesn't get attached right on launch, it is not possible to make code changes during runtime. With the slow startup, two things are coming together. No edit-and-continue might be ok when startup is fast, or a long startup might be acceptable when you can work while it's running (edit-and-continue).
When both are coming together - that's a real pain-point. Even though we got the slow startup fixed already, there's more to gain.
Launch Sequence
In order to debug the ASP.NET project, we need to have the debugger launch it directly. VS has the ability to debug multiple processes in parallel, but - unfortunately - not from a single project. Setting up an additional project just for debugging is possible but ugly and complicated. The only way to get what is needed here is to have the debugger launch the ASP.NET project and let the ASP.NET project then launch the Electron app.
But we can't easily change this for packaged applications. Since this is all Electron, they are relying on the Electron app to be started first and I don't think it's reasonable to change this.
Long story short: both ways are needed!
Launching ASP.NET First
Pretty much straightforward, just the other way round:
Debug Launch Profiles
So that's the result:
The Electron (unpacked) profile launches Electron and the other one the ASP.NET project for debugging.
(there will be more...)
I'm getting tired of writing - time for another demo!
@softworkz commented on GitHub (Feb 25, 2025):
Yea, well - when something sounds like too good to be true, it's hardly ever true. Exceptions are rare, talk is cheap - time for truth
🚀
Debugging Demo Pt 1
https://github.com/user-attachments/assets/319883cb-d972-490e-98eb-011771a416fe
Debugging Demo Pt 2
https://github.com/user-attachments/assets/9240a77f-7640-4d5f-9f00-1e5b5569434f
@FlorianRappl commented on GitHub (Feb 25, 2025):
I love it!
I think we should go that path.
Regarding selecting an Electron version; my idea was to have an adapter here - something like (names just to illustrate the idea)
Bridge implements Api, Core references / knows Api. One selects a version, which installs / uses a variant of Bridge that is compatible with the Electron version. This way Electron.NET is "independent" (to some degree) on Electron.
My idea was to start with a single / or two (at most) of the most popular Electron versions for the Bridge. Most of the time - as already written - a new Bridge / support for a new Electron version is really easy to establish. This could also be backwards compatible, i.e., if Api gets a new feature that is only there in a new version of Electron, then older Bridges might still implement it as a stub / just to be compatible.
@softworkz commented on GitHub (Feb 25, 2025):
Hi Florian,
this sounds very good to me - especially because this fits together pretty nicely as it's something that I'm not able to cover, not even having good ideas for - same like many other things
Actually, I'm quite limited in time (spent no more than a week so far) - BUT in this case: I've been rolling the idea since 1.5 years already. It kept being an attractive wannadoo project for me, because I knew that I could make a huge difference with comparably little work. And that would also be my recipe for contribution: focus on those areas only, where I can bring in high value.
Even though I'm having this in mind for so long, I hadn't expected this to happen (kind of forced, maybe 50-50 :-)
The more I am happy to see that you guys are still having some heart in this project and you'r open to moving forward with it !!
@softworkz commented on GitHub (Feb 25, 2025):
I haven't tried to fully ingest your idea, so what I'm saying is more from general consideration: I think I' should also build and look at some diffs of Electron APIs from version to version to get a feeling about what we're talking here.
My personal preference when it comes to such things like APIs or other subjects of versioning management and adaption is automation in whichever form may be applicable, be it auto-generation, auto-parsing, both, or else.
Each time when somebody came to me, asking to do any kind of repetitive work, my first thought has always been: "no way, I'm not gonna do this", but I said: "I might be able to help you in a way that nobody will ever need to do it manually".
This has brought me a lot of successes, even where others were laughing in the first moment. One example is ffmpeg, which you surely know. We're using it out-of-process via command line. Command line building has been somewhat error-prone. At some point, I built an object model for building command lines (in C#) - but there was still a lot of room for errors. So I built a generator which reads the help output and parameters info for every single feature that is available, auto-generating a C# object model which precisely reflects the CLI, (data types, min, max, enum values etc etc.). It's an object model with hundreds of classes and thousands of properties. This allows fully-typed access to ffmpeg features and options in the code, all for the single and sole purpose of generating a command line string. It had brought us a lot of benefits and advantages over the competition, but the specific point I'm up to is this: whenever we switch to another (newer) ffmpeg version, we rebuild that object model for the new version.
The result of this: Every single feature, option or parameter that has been removed or changed in some way is then causing a compilation error - because it's no longer part of (or different in) the new object model.
So - while others need to wait for each of those update issues being reported by users and tediously investigated until the cause is identified, we knew about those issues even before publishing a beta version. I like this example, because it appears idotic at first, before shifting one's perspective.
Circling back to Electron.NET. It's a great project, there's not really anything like it, but there's a substantial stagnation of interest since 2023. I don't think there's much to wonder about the predominant reason for that:
It's outdated and appears to be somewhat / somewhat-not abandoned, yet at least not under active development.
It doesn't matter to people whether Electron 23 is still a good choice, they want to see progress and activity to gain sufficient confidence to go with it. In the most extreme case: Even when it's the same package for several years and it only gets released regularly with new version numbers - that's still a night+day difference (for the better).
And that's where automation can turn things upside down for good. I don't have anything specific in mind. I also don't have an understanding yet of what or how it could be and what's possible. Maybe not fully but at least partially automatied, so that it takes just a few hours of manual work for releasing a new version.
Ideally - as soon as there's a new Electron release, an Electron.NET release for the same versiion would follow within a few days.
Summing Up
The above is probably a bit extreme and overdriven - my original thought I wanted to express is that whichever model for API verionsing and compatibility we would choose, it shouldn't too much depend on individual/manual work, because this will always cause stalls in progress - just naturallly - we're' all shifting focus here or there over time.
@softworkz commented on GitHub (Feb 25, 2025):
I actually wanted to keep this for tomorrow, but I'm so excited to share it with you - can't hold it back...
WSL/Linux Demo
https://github.com/user-attachments/assets/42b4b651-e08c-4bd7-93ba-cfedda54cd9d
@softworkz commented on GitHub (Feb 26, 2025):
Yea, this would lead to a correct result, but it would also put quite some burden on us to maintain it over time.
I have an idea for how we might be able to accomplish something similar in a cheaper way (i.e, with less work). Essentially it's not my own idea, blatantly stealing from how it's done for the Android API and reflected to .net by Xamarin/Android accordingly, albeit a bit simplified.
API Decoration
The basis would be that we implement the Electron API as a UNION across versions, means: "Everything from Electron 23 to 34".
We could add the following to our .net API:
ElectronMajorVersionV23, V24, ..., V34
(or do they have API changes in minor updates as well? then we could use something like V23_3, etc.)
ElectronVersionFrom(ElectronMajorVersion version)ElectronVersionUntil(ElectronMajorVersion version)ElectronVersionNote(ElectronMajorVersion versionFrom, ElectronMajorVersion versionFrom, string note)Then we can use those attributes to decorate everything in our API:
For the (hopefully rare) cases of truly breaking changes (like incompatible method signatures, where parameters change and don't just get appended), we can add compatibility members. For example:
When parameters are just added, we can add them as optional (with default null) like this:
.NET Analyzer
Finally, we could create an "Analyzer" dll. This would need to be implemented just once and will never need to be updated. We can get inspiration for how it's done from the Xamarin code.
The analyzer will check the usage of our APIs with regards to the selected Electron version. Any usage of API members which are incompatible with the user's selected Electron version will show up as an error during compilation.
Semi-Automated Version Maintenance
This would allow us to automate large parts of maintenance when new Electron versions are released:
ElectronVersionFromandElectronVersionUntilcan be applied automaticallyI don't think this will be a lot stuff from version to version, and when we know exactly what needs to be done (without making tests and reading docs, studying release notes, etc) - we should be able to quickly make those few changes to release a new version
As we don't have any commitment to provide full coverage of Electron APIs anway, I would expect that quite often there's no manual intervention needed at all and we can just press a button to release a new Electron.NET nuget package version.
What do you think about this?
@FlorianRappl commented on GitHub (Feb 26, 2025):
By including all kinds of APIs you will force to have a new release of the main package, which, naturally requires more resource (e.g., more testing). Also, if we ship all APIs in a single API then you will incl. unnecessary bloat in "your" (i.e., Electron.NET end-users) codebase, too. The adapter pattern could be cheaper / at most as much effort imho, as the API is abstracted away. The specific adapters could be auto-generated, too.
@softworkz commented on GitHub (Feb 27, 2025):
Yea, it was just an idea, if you think that yours will cause less effort, then that's the way to go of course.
What I'm wondering...do you actually know an Electron API in Electron 33 or 34 that is incompatible with the current implementation (targeting 23)?
The only thing I know is that BrowserView is deprecated (but still working)..
@FlorianRappl commented on GitHub (Feb 27, 2025):
No - for the API surface that we cover we should be fine. In many / most cases I also think that the difference(s) between two versions of Electron should be rather small - if any.
@softworkz commented on GitHub (Feb 27, 2025):
I had a done a quick diff of their TypeScript definitions between 23 and 34. It's really huge, so you can't easily go through everything, but I looked at a few classes and in almost all cases, it's just additive, rarely breaking, so once we get everything canned and able to emit new versions, I'm quite confident that interest will grow again.
From my side, the remaining point is publishing (packaging). I'm halfway there, though.
Not sure how you want to do it, I thought a branch would be useful for working, then I can submit PRs against that branch..?
@agracio commented on GitHub (Sep 2, 2025):
I would be happy to contribute to this repository as well. There are a few items I would like to address.
@softworkz commented on GitHub (Sep 2, 2025):
I'm still waiting for a new branch, then I'd push (if given permission to that branch or otherwise PR) my changes.
Meanwhile, I got driven things so far, that I can launch and debug the Electron app on WSL Linux, where I run full DEs (Desktop Environments) like Gnome, KDE Plasma, xfce4, Cinnamon, etc. on Ubuntu, even with X11/Xlib programming for window manipulation from .net via P/Invoke.
(of course, that part is outside the scope of Electron.NET, but it's crazy which possibilities this is opening up...)
@agracio commented on GitHub (Sep 2, 2025):
Did you update Electron to newer version, I am looking at version 38 .d.ts definitions right now.
While running on Linux is always a plus how are things on macOS side?
Btw Electron.NET is actually extremely popular v23.3.13 is the second most downloaded version on NPM https://www.npmjs.com/package/electron?activeTab=versions and there is no other reason for that. It would be a real shame if this repo will become absolete.
@softworkz commented on GitHub (Sep 2, 2025):
The Electron version is selecatable:
I'm currently using 30 without issues.
That might be better - BUT ONLY if there would be somebody who is creating, validation and releasing such versions.
Realistically this is not going to happen unless there would be a sponsor or volunteer supporting Floran and Gregor in this regard, so we should lower expectations.
By allowing a free selection of Eelctron versions, we turn the situation around:
This prevents the project from standing still and encourages contributions. It also sets expectations straight and avoids disappointment.
Haven't tested recently. When it works on Linux it very likely works on Mac as well, but you'll have to try it out.
@agracio commented on GitHub (Sep 2, 2025):
To be honest I completely disagree with this approach, since definition differ from version to version Electron.NET cannot be compatible with multiple versions, even 38 has some differences to 37 resulting in method incompatibility. Expecting 23 and 38 to work in the same space is not reasonable. Not sure how this would encourage contributions.
Bumping versions sequentially for example from 37 to 38 and so on is a minimal amount of work, its the leap from 23 to 38 that is a huge undertaking.
If we were to take approach of Electron supported version then its 36, 37 and 38 that should be released and then next releases would slowly follow Electron release schedule.
@softworkz commented on GitHub (Sep 2, 2025):
There are other reasons. You can see Electron.NET figures here without needing to make any assumptions: https://www.nuget.org/packages/ElectronNET.API
@agracio commented on GitHub (Sep 2, 2025):
True but Nuget represent lifetime download number while NPM shows last 7 days download number. So 100k total nuget downloads of 23.3.13 vs 73k NPM downloads in last 7 days.
@softworkz commented on GitHub (Sep 2, 2025):
If you would be willing to do the work and keep maintaining this, you are very welcome!
Exactly. And when the lifetime download count of ElectronNET 23 is 100k since February 24, it can't be the reason for 70k Electron npm downloads pet month.
@agracio commented on GitHub (Sep 2, 2025):
I was wondering the same about both some of my NPM packages and especially some of most popular NPM packages that have millions of downloads in 7 days. So far my conclusion is CI runners that pull those packages from NPM on a daily as well as dependencies on those packages.
If we look at Electron specifically except for latest version no version even comes close to 23.3.13 unless there is another very popular package that has a dependency on Electron 23 I thing its due to Electron.NET. I have a feeling that .NET CI maintainers are much better at cashing Nuget packages than they do NPM.
I do believe that the work is minimal so sure I could do that but we need some kind of response from repo owners.
@softworkz commented on GitHub (Sep 2, 2025):
I agree to the assessment that there must be a popular package pulling this version. But it's not Electron.NET. Current Electron.NET is pulling 23.2.0:
https://github.com/ElectronNET/Electron.NET/blob/main/src/ElectronNET.CLI/Commands/BuildCommand.cs#L201
... and electron-builder is taking that as an exact version.
@agracio commented on GitHub (Sep 2, 2025):
npm installwill always take latest major, when running Electron.NET demo it installs 23.3.13. https://github.com/ElectronNET/electron.net-api-demos@softworkz commented on GitHub (Sep 2, 2025):
Not when you build and run.
@agracio commented on GitHub (Sep 2, 2025):
You right but I am sure CI tests of some sorts are not running on pre-built version, there are likely plenty of cases when it runs
electronize startbut of course its a pure speculation on my side.Now unless we hear from repo owners I am not sure if it is worth starting on creating a version for 36, 37 and 38.
36 would be the biggest change and then 37 and 38 would be just a couple of minor changes.
Btw I am not that familiar with Nuget publishing policies as I only have a single package there, does it allow to publish a lower version of a package. Lets say we have Electron.NET 36.0.0 published and after that we publish 37.0.0, will nuget allow to publish 36.0.1?
NPM allows to publish packages that way using tags.
@softworkz commented on GitHub (Sep 2, 2025):
The idea is right, but each CI run (where a fresh version is built), also needs to download the nuget package, and both - nuget and npm packages - are cached, so it doesn't matter how often each of those packages is "installed" during a CI run. Both are downloaded once (unless it's a private runner which keeps state).
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.
@agracio commented on GitHub (Sep 2, 2025):
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.
@agracio commented on GitHub (Sep 3, 2025):
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.
@softworkz commented on GitHub (Sep 3, 2025):
Let's continue here please https://github.com/ElectronNET/Electron.NET/issues/891
This is drifting off too far from the actual topic.
@softworkz commented on GitHub (Sep 7, 2025):
@FlorianRappl @GregorBiswanger
Please let me know how you want to proceed.
@softworkz commented on GitHub (Sep 28, 2025):
@FlorianRappl @GregorBiswanger
What are your intentions about this?
@FlorianRappl commented on GitHub (Oct 9, 2025):
Thanks for being persistent on this one. I think this might be really awesome to get live and make it the default experience.
Reason I did not get involved earlier is because I am pretty much out of time and I did not even tinker with it for a bit. But maybe we can bring this to a dedicated branch and release it as a preview version? Then we can announce it as an RFC to the community, gather feedback (especially on migration / update details) and - if it seems to be suitable overall - put it in as the next version. In my opinion it solves a lot of problems. So much appreciated @softworkz !
@softworkz commented on GitHub (Oct 9, 2025):
8 months have passed since my original offer. Meanwhile, our new Linux app is right in the middle of beta testing and completion has become foreseeable.
Linux is a very heterogenous landscape - there are not only a lot of different distros but also a range of desktop environments, which in turn can work in combination with different distributions. Since we do native video playback integration, a lot of X-Windows development was required in combination with Electron's window management, which was/is challending, because every system behaves differently.
I had encountered similar issues with the Electron.Net app lifetime. Too often, an electron or .net process (or both) didn't terminate properly on close. I suppose you know about this - otherwise you wouldn't be hard-killing the .net process in main.js (
apiProcess.kill()). It might not have much side effects for .net code, but when you are loading and running native libs in that process which are accessing various low-level graphics apis, killing cannot be the standard method for app exit.(as a side note:
server.close()is not awaitable, it doesn't return a Promise)These issues had brought me to a fundamntal change: I've turned the startup sequence and process relations in a way that the .net app is in charge: it is launched first and exiss last and runs electron as a child process(es). This provides a lot more control than the Electron.Net way, where main.js is a deliverable of the framework and not (easily) accessible for making changes.
Also, there's a mismatch between a server application process like asp.net is developed for, and a desktop client application (like what you want to build with Electron.Net). Since our htmljs code runs from the file: system, we actually have no need for Asp.Net (and we already have our own cross-platform app framework aside anyway), so I entirely removed all ASP.Net stuff from Electron.Net, so that it's just a lightweight console app on the .net side.
I made all those changes without caring about compatibility, as I sensed that there's no real interest here for a restart. My work in this area is almost complete and it won't take long until my focus of work is a different one, so I'm afraid to say that my offer no longer stands - that window is closed, unfortunately.
Going forward, it might be helpful for new users to mark this repo as archived or add a disclaimer that people should do careful judgement before making a choice for using Electron.NET, so that it doesn't end up in a bad surprise.
Anyway - no hard feelings - same like I know that I won't have any time for this after completion for development, I very well understand everybody having their own priorities. Sometimes - with a little luck - these may align, and sometimes not at all.
I wish you all the best and once again thank you for the work on this project!
sw
@softworkz commented on GitHub (Oct 9, 2025):
I started this with a number of videos, goying beyond the expected, and so I'll also close up with something that probably hasn't been seen before...
The diversity on Linux kind-of forced me to find an efficient way for development and testing the Linux app across various Linux Desktop Environents. Eventually, I got my self surprised of what I managed to achieve...
https://github.com/user-attachments/assets/d4ba78a1-b323-4ae7-ad4b-eabc34750ad8
@softworkz commented on GitHub (Oct 9, 2025):
You know what? I didn't respond to your message. I wrote these two message before even having seen that you have replied. Crazy coincidence...
@GregorBiswanger commented on GitHub (Oct 10, 2025):
Can the new architecture and ideas already be tested?
@softworkz commented on GitHub (Oct 10, 2025):
If you create a new branch, I can make a PR against that branch (or you give me push rights just for that branch.
@softworkz commented on GitHub (Oct 10, 2025):
To elaborate a bit more:
Currently, I am pushing to and consuming the packages from a private package feed (not nuget), to avoid conflicts.
Versioning
I've started at version 50.0.0 and the latest is 50.0.20, but we could use an entirely different versioning of course, let me know what you would find reasonable.
Nuget Packages
There's no more .Net tool needed, so there isn't a ElectronNET.CLI package anymore.
Now there are still these three packages:
This is essentially the same as the existing API package, but I think it might make sense to give it a different name than before to avoid confusion, because people who are upgrading will normally want the "full package" instead and the upgrade should be explicit rather than just bumping the version of the existing nuget package
This is what you normally want to use when updating. It has the API package as a dependency and bring all the build logic (MSBuild) and the VS project modifications (the project designer in VS where you can enter all the values for ElectronNet).
This would have a dependency on the API package and include the ASP.Net integration that I've removed from the API package, so that it can be used in non-ASP.Net projects
Background
The reason for having a separate project and API package stems from the fact that you may have a multi-project architecture where there is one "startup" project - from whch the Electron app is built, but also additional projects which need to interact with Electron APIs. The separation of ASP.Net intgration is explained above.
For upgrading an existing project, you would reference the project package (which included the API package) and the AspNet package - still very simple.
Required Decisions
I'm unsure how to go about the package naming and versioning. Following thoughts:
The first part of the package names ("ElectronNET") should probably remain the same or similar, so people realize that it's not a fork, so either stick to ElectronNET or maybe use ElectronNET2?
The API package should have a different name than before, means: no longer ElectronNET.API.
Ideas would be:
Versioning: Not sure, we could start at 1.0.0 or 25.0.0 or 30.0.0, etc.
What to expect
In the branch I will submit, you will be able to do everything I've shown in the videos. You'll be able to run and debug on Windows and Linux/WSL from Visual Studio. You will be able to build electron packages for Windows and Linux right from within Visual Studio. You will be able to build Windows packages via dotnet publish on Windows and you will be able to build Linux packages via dotnet publish on both, Windows and Linux.
I can write a short upgrade guide and provide an upgraded sample project.
@FlorianRappl commented on GitHub (Oct 10, 2025):
I'd stick to ElectronNET.
I'd vote for
ElectronNET.Core(had the same idea, and you listed it, too - I like it).Depends - how "independent" are we from Electron itself? If we are fully independent then I'd say let's go with 1.0.0 ("fresh start" as its anyway a new package name) otherwise I'd go for whatever version of Electron is the minimum version (e.g. let's go for 30.0.0).
Would be superb. Actually I'd not only support you as much as possible but I'd also sponsor these efforts. Since you seem to be also from Munich I'd invite you for lunch or dinner :) 🍻
Thoughts @GregorBiswanger ?
@softworkz commented on GitHub (Oct 10, 2025):
Fine!
So ElectronNET.Core, ElectronNET.Core.Api and ElectronNET.Core.AspNet ?
More like "fully independent". But definitely no more in a way that a specific version is bound to a specific version of Electron.
We can rather indicate Electron version support by
(one can still enter a newer version in the .csproj directly)
For too old versions of Electron and electron-builder where we would know that they're incompatible, we can also emit a build error, so that users recognize early that it won't work. So - lots of options here.
Sounds great, thanks for the invitation 😄
@agracio commented on GitHub (Oct 11, 2025):
I am not sure how different the new code will be from the original Electron.NET but was recently looking through a code of a modernised forked Electron.NET implementation and noticed a lot of repetitive code around events and tasks.
Performing some basic refactoring removed close to 1500 lines from codebase and there are more instances that can be optimised however I have not invested too much time since the owner of that project is also too busy to maintain it.
Other optimisations would be to normalise event and tsk names and there are many more.
The forked project has more Electron APIs implemented and there are many more that can be added.
I would be interested to contribute to this project but to be honest only offering to re-engage since a number of replies in this topic were deleted but still feel unsure if this is the right working environment for me.
@softworkz commented on GitHub (Oct 11, 2025):
No messages were deleted. You need to scroll up and find this button:
This is GitHub behavior when conversations become too long.
@softworkz commented on GitHub (Oct 11, 2025):
The API part remains largely untouched, so that will be fully compatible not needing any code changes.
My update does all the things shown in the videos above
but nothing more<< edit: plus some nice details, unmentioned yetThat would surely be very welcome. Please let's start a new discussion for that (this one is long enough 😄 )
Thanks
@agracio commented on GitHub (Oct 11, 2025):
You are correct I was referring to https://github.com/ElectronNET/Electron.NET/issues/891 and at first glace it appeared that some messages were missing. But as you pointed out no messages were deleted.
I agree that this one is way too long but there is no point in starting new discussion before seeing the new code and possible contributions.
A simple example:
https://github.com/agracio/electron-sharp/blob/refactoring/ElectronSharp.API/BrowserWindow.cs is 1633 lines of code vs original https://github.com/theolivenbaum/electron-sharp/blob/main/ElectronSharp.API/BrowserWindow.cs 2120 lines of code.
If your code is similar to the original then same optimisations can be performed but let's start that discussion once new code is available.
@softworkz commented on GitHub (Oct 12, 2025):
@GregorBiswanger - Hi Gregor, what are your feelings about how to proceed? I think it would be soemwhat counterproductive to put it on a softworkz/ElectronNET repository as there will hardly pass anybody by - and maintaining "my own fork" isn't really a goal. If you want to see it first, a temporary repo under
/github.com/ElectronNET/might be an option for reviewing it before getting anything in the main repo.Yet, I believe that any kind of visible activity would be beneficial for the project, especially talks about the new capabilities - in a separate repo, people wouldn't notice as they're not subscribed there.
That's why I suggested a branch in the main repo, but not like something 'official' yet - more like "temp_test" or similar.
What do you think?
@FlorianRappl commented on GitHub (Oct 12, 2025):
My suggestion is to make a PR and have it the preview branch of this repo (
develop). This triggers a pre-release from the branch (using the names we agreed on). I would then after a period of 2-3 weeks move fromdeveloptomain(triggering a full release).I think @GregorBiswanger agrees with the process. If we are all on the same page then let's do it 💯
@softworkz commented on GitHub (Oct 13, 2025):
Okay, great!
This weekend, I've integrated my detour mentioned above (using a plain console app instead of ASP.Net) to make it officially supported.
In this context, I've also reworked the startup procedures - of which there are 8(!) different ones now:
It can be launched by DotNet or by Electron, it works for packaged or unpackaged and for console or ASP.net apps => 2 x 2 x 2 = 8
I've tested these for Windows and Linux/WSL => makes 16: I've tested all the green dots:
(please note that by "unpacked", I do not mean the
linux-unpackedorwin-unpackedoutput from electron-builder - that's already the packaged layout; by unpackaged I'm talking about the file layout used for debugging where no app.asar is generated and all is running from the file system with a different folder layout)Essentially, with all outputs, you can execute eiither the dotnet binary or the electron binary and it will always launch the other. Before I had a blocker to prevent launching from the Electron side, but since that is not appropriate for the project I've removed this (will find a different way).
@softworkz commented on GitHub (Oct 13, 2025):
It's there! Ready for tryout: https://github.com/ElectronNET/Electron.NET/pull/893
@FlorianRappl commented on GitHub (Oct 31, 2025):
Merged into
main!Thanks a lot @softworkz - everything is awesome. Please response to my mail for dinner sometime!