Separate Product Name and Executable Name #1047

New Issue

claunia · 2026-01-29T16:56:33Z

claunia commented

2026-01-29 16:56:33 +00:00

Originally created by @AeonSake on GitHub (Jan 2, 2026).

Currently, the name of the Electron executable output/artifact is determined by the Title field in the project/publish configuration (fallback to MSBuildProjectName). There is currently also the rather hidden ElectronExecutable field available for further customization, but that only affects the C# binding name for the Electron executable, not the actual output itself.

I would like to propose to make ElectronExecutable the actual executable name (fallback to Title or MSBuildProjectName if needed/for backwards compatibility) and use the Title only for the product name. In the electron-builder configuration, this would mean:

Title maps to productName (which I believe it already does right now)
ElectronExecutable maps to executableName (which so far used productName)

This way, we could also (theoretically) clean up any illegal file characters without affecting the application title itself.

Originally created by @AeonSake on GitHub (Jan 2, 2026). Currently, the name of the Electron executable output/artifact is determined by the `Title` field in the project/publish configuration (fallback to `MSBuildProjectName`). There is currently also the rather hidden `ElectronExecutable` field available for further customization, but that only affects the C# binding name for the Electron executable, not the actual output itself. I would like to propose to make `ElectronExecutable` the actual executable name (fallback to `Title` or `MSBuildProjectName` if needed/for backwards compatibility) and use the `Title` only for the product name. In the `electron-builder` configuration, this would mean: - `Title` maps to [`productName`](https://www.electron.build/configuration.html#productname) (which I believe it already does right now) - `ElectronExecutable` maps to [`executableName`](https://www.electron.build/configuration.html#executablename) (which so far used `productName`) This way, we could also (theoretically) clean up any illegal file characters without affecting the application title itself.

claunia added the Feature label 2026-01-29 16:56:33 +00:00

claunia commented

2026-01-29 16:56:34 +00:00

@AeonSake commented on GitHub (Jan 2, 2026):

Looking at the package.json template, it looks like only Windows and macOS executables may be affected by this. The Linux executable has a manual overwrite specified to use ElectronPackageId instead. It would still be a good idea to separate the two name types into individual fields rather than using the Title for everything.

@AeonSake commented on GitHub (Jan 2, 2026): Looking at the [`package.json`](https://github.com/ElectronNET/Electron.NET/blob/7e6760a42800b67a22056ce04dd27b27d9f5ca01/src/ElectronNET/build/package.template.json) template, it looks like only Windows and macOS executables may be affected by this. The Linux executable has a manual overwrite specified to use `ElectronPackageId` instead. It would still be a good idea to separate the two name types into individual fields rather than using the `Title` for everything.

claunia commented

2026-01-29 16:56:34 +00:00

@softworkz commented on GitHub (Jan 2, 2026):

I would like to propose to make ElectronExecutable the actual executable name

No. The ElectronExecutable does not control the name of the built executable in the packages. It simply follows what electron-builder is doing and there are only rare cases where you want to change it, like for example when you do some custom package manipulations via electron-builder's build hooks, like for example you could add a stub script to the package and want that to be called by Electron.NET instead of the actual electron executable.

In other words: If you change ElectronExecutable to a different value, your app would not launch anymore - unless you put something into the package which has that value as its file name.

That's the reason why it is kind-of hidden.

@softworkz commented on GitHub (Jan 2, 2026): > I would like to propose to make `ElectronExecutable` the actual executable name No. The ElectronExecutable does not control the name of the built executable in the packages. It simply follows what electron-builder is doing and there are only rare cases where you want to change it, like for example when you do some custom package manipulations via electron-builder's build hooks, like for example you could add a stub script to the package and want that to be called by Electron.NET instead of the actual electron executable. In other words: If you change ElectronExecutable to a different value, your app would not launch anymore - unless you put something into the package which has that value as its file name. That's the reason why it is kind-of hidden.

claunia commented

2026-01-29 16:56:34 +00:00

@softworkz commented on GitHub (Jan 2, 2026):

I know that this all looks somewhat messy, but it's electron-builder doing that and we are just following.

@softworkz commented on GitHub (Jan 2, 2026): I know that this all looks somewhat messy, but it's electron-builder doing that and we are just following.

claunia commented

2026-01-29 16:56:34 +00:00

@AeonSake commented on GitHub (Jan 2, 2026):

I would like to propose to make ElectronExecutable the actual executable name

No. The ElectronExecutable does not control the name of the built executable in the packages. It simply follows what electron-builder is doing and there are only rare cases where you want to change it, like for example when you do some custom package manipulations via electron-builder's build hooks, like for example you could add a stub script to the package and want that to be called by Electron.NET instead of the actual electron executable.

In other words: If you change ElectronExecutable to a different value, your app would not launch anymore - unless you put something into the package which has that value as its file name.

That's the reason why it is kind-of hidden.

I know it doesn't control the name right now, but I would like it would do so. As far as I can tell, it's as easy as using the field in the package template instead of leaving it blank as it is right now (electron-builder itself will then fall back to productName).

I really disagree using the Title field as the executable file name. It will include e.g. also whitespace, which you might want to preserve for the product name but not the file name. That's the exact reason why there even is a manual overwrite for Linux in the template (according to the comment).

@AeonSake commented on GitHub (Jan 2, 2026): > > I would like to propose to make `ElectronExecutable` the actual executable name > > No. The ElectronExecutable does not control the name of the built executable in the packages. It simply follows what electron-builder is doing and there are only rare cases where you want to change it, like for example when you do some custom package manipulations via electron-builder's build hooks, like for example you could add a stub script to the package and want that to be called by Electron.NET instead of the actual electron executable. > > In other words: If you change ElectronExecutable to a different value, your app would not launch anymore - unless you put something into the package which has that value as its file name. > > That's the reason why it is kind-of hidden. I _know_ it doesn't control the name right now, but I would like it would do so. As far as I can tell, it's as easy as using the field in the package template instead of leaving it blank as it is right now (electron-builder itself will then fall back to `productName`). I really disagree using the `Title` field as the executable file name. It will include e.g. also whitespace, which you might want to preserve for the product name but not the file name. That's the exact reason why there even is a manual overwrite for Linux in the template (according to the comment).

claunia commented

2026-01-29 16:56:35 +00:00

@AeonSake commented on GitHub (Jan 2, 2026):

I know that this all looks somewhat messy, but it's electron-builder doing that and we are just following.

Electron-builder has explicit configuration settings to change the executable file name, but they are not used by the Electron.NET build pipeline as far as I can tell. Since you can specify the electron-builder configuration (or parts of it) also in the generated package.json file, setting the executable file name from the template shouldn't be an issue. And since electron-builder will load package.json first, and merge the separate config file on top, any custom configuration created by users will always win regardless.

@AeonSake commented on GitHub (Jan 2, 2026): > I know that this all looks somewhat messy, but it's electron-builder doing that and we are just following. Electron-builder has explicit configuration settings to change the executable file name, but they are not used by the Electron.NET build pipeline as far as I can tell. Since you can specify the electron-builder configuration (or parts of it) also in the generated `package.json` file, setting the executable file name from the template shouldn't be an issue. And since electron-builder will load `package.json` first, and merge the separate config file on top, any custom configuration created by users will always win regardless.

claunia commented

2026-01-29 16:56:35 +00:00

@softworkz commented on GitHub (Jan 2, 2026):

You're not building and distributing Linux packages, right?

@softworkz commented on GitHub (Jan 2, 2026): You're not building and distributing Linux packages, right?

claunia commented

2026-01-29 16:56:35 +00:00

@AeonSake commented on GitHub (Jan 2, 2026):

I've built and maintained several .NET applications for Linux (mainly servers), but never as a Blazor GUI App, no. But that's the main reason I'm using this project in the first place. The dev experience so far has been really great, but the publishing pipeline has been rather frustrating to be perfectly honest. But I'm not sure how that relates to the issue I've proposed. It's literally a setting for the electron-builder itself. Please explain, what the problem with that would be so I can understand it better.

@AeonSake commented on GitHub (Jan 2, 2026): I've built and maintained several .NET applications for Linux (mainly servers), but never as a Blazor GUI App, no. But that's the main reason I'm using this project in the first place. The dev experience so far has been really great, but the publishing pipeline has been rather frustrating to be perfectly honest. But I'm not sure how that relates to the issue I've proposed. It's literally a setting for the electron-builder itself. Please explain, what the problem with that would be so I can understand it better.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/Electron.NET#1047