mirror of
https://github.com/ElectronNET/Electron.NET.git
synced 2026-02-03 21:25:13 +00:00
Need advice regarding how best to contribute a universal binary js and possibly notarization js script(s) to the project #1038
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 @markatosi on GitHub (Dec 13, 2025).
I have these scripts to contribute AS-IS. I also will write documentation for them but I need to know where they should be placed in the repository as they are electron.net adjacent but not really part of the core project just something useful to have on hand if needed. The MakeUniversal.js is written now specifically for the new Electron.net though.
@softworkz commented on GitHub (Dec 14, 2025):
Can you outline how this works?
Especially at what moment it needs to get invoked. If it requires two publish operations first and only works on the generated output afterwards, then I don't see a way to integrate it in a reasonable way, because a publish run is a top-level operation without any over-arching process which could invoke that script.
(but otherwise, chances are increasing at least..)
@markatosi commented on GitHub (Dec 15, 2025):
This isn't anything that you would need or want to integrate into the electron.net build process per se and it's primarily useful as a scaffolding for how to build a production electron.net/blazor application as a universal binary to the apple macos app store. You would need to have an apple developer account to use this script properly. It uses another npm package that does the actual stitching of the intel and arm packages and signing the application so that is can be submitted.
So the work flow is you develop your application as usual using the blazor, electron.net tooling and when you want to submit to apple you can use the command node MakeUniversal.js to build your application. If someone wants to integrate that script with their own CI/CD process that's up to them but has nothing to do with electron.net. So this script is just a contribution for others to utilize if they have a need and don't want to re-invent the wheel.
@softworkz commented on GitHub (Dec 15, 2025):
Understood, thanks for the explanation.
Then it would probably most suitable to have a sample app with this script included and instructions how to use, I suppose?
@markatosi commented on GitHub (Dec 15, 2025):
My plan is to have instructions in the wiki how to build an apple universal app for distribution in the app store and place the script(s) in a directory called contrib/apple-universal. People could then read the wiki and have a link to the necessary files that they would incorporate into their local project folder. An example app is probably OK it's just the example apple would never work on their end without modification because of the need to provide their own apple profile file plus other apple developer specific things which will be different for each developer/company depending on how they are electing to build/distribute their application in the apple ecosystem.
@softworkz commented on GitHub (Dec 15, 2025):
This might sound like a good idea from the perspective of someone who knows about it. But doing so is convoluting the project structure on one side and makes it difficult to discover on the other side. I've come across so many projects and so many times couldn't find what I was looking for until I - much later - accidentally found it in some corner I hadn't looked at, or hidden in some discussion).
I know that there is only moderate value for the sample per-se in this case, but there is value in having a consistent structure - just very stupidly:
Use case => sample
Use case => sample
Use case => sample
...rather than "this time, we do it this way" and "that time, we do it that way"
The sample itself will still build and that the script requires parameters in order to run should be clear anyway.
@softworkz commented on GitHub (Dec 15, 2025):
Also - eventually - I still think that the samples should be published to a separate repository (always updated to the latest nuget packages versions). As a library consumer, you should not be required to clone the full source repo of the library, just to get sample code/apps.
@markatosi commented on GitHub (Dec 15, 2025):
This sounds fine. I'll go the sample route but there still needs to be guidance via the wiki that people can use to understand what is going on under the hood, plus other helpful advice on how to setup their electron-builder.json file for publishing to the app store or ad-hoc. Apple makes this process arcane and frankly frustrating and throwing electron in the mix makes it all the more frustrating so if i lighten the load for someone regarding this process i'm happy to do so.
@FlorianRappl commented on GitHub (Dec 15, 2025):
Wonderful - thanks a lot @markatosi. Much appreciated!
@softworkz commented on GitHub (Dec 15, 2025):
Right. Short hints in the sample, long explanation on the Wiki would be perfect.
@softworkz commented on GitHub (Dec 15, 2025):
@markatosi - Here's something you might like (and probably others as well):
https://github.com/ElectronNET/Electron.NET/issues/987
@markatosi commented on GitHub (Dec 16, 2025):
That is very very cool.
@markatosi commented on GitHub (Dec 16, 2025):
As an update I have finally gotten the universal build script in a state that is usable by people other than me. I'll start work on the sample(s) soon. Although Tahoe is the last version of macOS that supports both intel and Arm the universal build will still be useful until apple decides they will no longer allow distribution of intel builds either in the app store or ad hoc. Development will be a problem for silicon mac owners trying to build intel distributions once they drop Rosetta but whatever... not like all the intel macs just cease to exist because apple says so.