electron-builder: Provide correct output path #942

softworkz · 2025-11-18T21:47:18Z

This had gotten lost somehow in my original PR.

Copilot

Pull Request Overview

This PR moves PR comment creation to a separate workflow using pull_request_target trigger. The change updates the electron-builder command configuration to explicitly specify the output directory using the ElectronPublishUrlFullPath property.

Key Changes:

Modified the electron-builder command to include an explicit output directory configuration parameter

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

softworkz · 2025-11-18T22:36:26Z

@FlorianRappl - Can we merge this? It broke my build (after switching to our new packages from here)...

FlorianRappl · 2025-11-18T23:53:38Z

src/ElectronNET/build/ElectronNET.LateImport.targets


    <PropertyGroup>
-      <_NpxCmd>npx electron-builder --config=./$(ElectronBuilderJson) --$(ElectronPlatform) --$(ElectronArch) -c.electronVersion=$(ElectronVersion) $(ElectronPaParams)</_NpxCmd>
+      <_NpxCmd>npx electron-builder --config=./$(ElectronBuilderJson) --$(ElectronPlatform) --$(ElectronArch) -c.electronVersion=$(ElectronVersion) -c.directories.output &quot;$(ElectronPublishUrlFullPath)&quot; $(ElectronPaParams)</_NpxCmd>


I think I removed that (need to verify). For me this resulted in a recursive loop as the output was in the same directory as the signing. That was really bad.

Since the output is anyway placed in the CWD (which is the publish directory) I don't see the direct reason for this. For me, the publish only worked when this was removed. Maybe it was an edge case, but I used a new project with a default publish config.

The point is that the output should go in the directory that you specify in the publish profile.

When I publish the WebApp with the included profiles, all is working fine. In which configuration did it fail for you?
(electron-builder)?

When the output is not specified, it writes the output into a "dist" folder instead of the publish output folder.

Maybe you ran publish without profile and without specifying a publish output folder?

No I published with a profile. And it published to the given directory, however, it got stuck in the process (as described) and the signing tool started go berserk (only seen with verbose flags provided, otherwise all of that is hidden).

The error is really nasty and as written you don't need that flag. The PublishUrl we use to specify the CWD, so I don't see why we should double it. For me it only caused havoc.

Even if I would not have published without a profile I don't why we should specify this. The error is really nasty as it does not only stay hidden (and fails to complete the publish process), it also eats up essentially all the disk space if not stopped in time.

Again, as the publish is done in the CWD and the electron-builder just works as designed I don't see why we should be explicit here. Have you maybe skipped signing?

Ah, I think it's when

`<ElectronNetDevMode>true</ElectronNetDevMode>`

is enabled.

I have seen this with the actual packages, but I guess / fear that with the dev mode it might also be true. TBH I think the actual problem is within the electron-builder. Even setting some directories as ignored did not help. It should never act like this. But we can't patch / change the electron-builder.

FlorianRappl · 2025-11-19T00:07:56Z

an we merge this? It broke my build (after switching to our new packages from here)...

No, this breaks my publish process (recursive creation of directories & files). The error here is really nasty. We first need to check if this is still the case.

Can you specify how it breaks your build? The electron-builder runs in the CWD specified as the publish directory and for me this is all that's needed. It will work with the defaults just fine. What exactly is breaking if used with the defaults?

softworkz · 2025-11-19T00:16:30Z

Can you specify how it breaks your build? The electron-builder runs in the CWD specified as the publish directory and for me this is all that's needed. It will work with the defaults just fine. What exactly is breaking if used with the defaults?

That's a bit tricky. There is a fundemental different between MBuild publish for AspNetCore and a normal projects. That's why we're seeing different things.

softworkz · 2025-11-19T00:18:31Z

It's also not the same path. One is ElectronPublishDirFullPath and the other is ElectronPublishUrlFullPath which are IIRC same in one case and different in the other.,

No, this breaks my publish process (recursive creation of directories & files). T

Using the actual packages or with ElectronNetDevMode set true?

softworkz · 2025-11-19T00:21:09Z

With the current package, when publishing from VS (console app), it goes into:

project\obj\x64\Release\net8.0\linux-x64\PubTmp\dist\

instead of here:

project\publish\Release\net8.0\linux-x64\

FlorianRappl · 2025-11-19T00:22:32Z

Using the actual packages or with ElectronNetDevMode set true?

Actual packages.

There is a fundemental different between MBuild publish for AspNetCore and a normal projects. That's why we're seeing different things.

That's true. My scenario was an ASP.NET Core project. Presumably, we maybe should add a flag / only use it if the directories won't match / overlap?

softworkz · 2025-11-19T00:24:45Z

Let me check what's happening. It has been working fine for a long time. I've switched to the console model just very recently.

I see what's happening. Nested folder ad infinity - explorer and VS are crashing...

FlorianRappl · 2025-11-19T00:29:03Z

I see what's happening. Nested folder ad infinity - explorer and VS are crashing...

Yes, that is what occurred on my system. Did I mention that this was "nasty"? Windows actually had problems deleting the folder as the depth was too high...

softworkz · 2025-11-19T00:35:13Z

I see what's happening. Nested folder ad infinity - explorer and VS are crashing...

Yes, that is what occurred on my system. Did I mention that this was "nasty"? Windows actually had problems deleting the folder as the depth was too high...

Right. Even rd /S has crashed cmd.exe 😆

I don't know whether I've ever seen cmd itself crashing...

But PowerShell did it.

One thought: Maybe it's Windows-specific. I've tested all the publishing before submitting the first PR, but maybe not Windows as target.

What is this signing anyway? What does it want to sign and how - without a cert?

FlorianRappl · 2025-11-19T00:43:27Z

I am 100% sure its Windows specific. My guess is that electron-builder has a problem with the backslashes and compares unix formatted paths with the Windows paths. In Node.js both are equivalent, but if you string compare... well - then two equal paths are no longer equal.

softworkz · 2025-11-19T00:55:03Z

You made another change:

That's what broke it and caused the recursion. The recursion came from the woing path and this parameter: -c.extraResources "bin/**/*" (which is right, though)

softworkz · 2025-11-19T01:01:35Z

I've updated this PR accordingly.

src/ElectronNET/build/ElectronNET.LateImport.targets

softworkz · 2025-11-19T07:02:40Z

Update

Everything good on my side - the pipelines are creating the right output again now
I tried publish of the WebApp after removing the trailing backslash in the PublishUrl => no problem
Yet I noticed a new issue: I have broke something around HostHook with the recent project (and compilation) change for ElectronNET.Host
need to investigate further...

FlorianRappl · 2025-11-19T08:28:37Z

@softworkz

Originally that change originated from #900 - I just tested the latest release (preview version) and the issue is back with your changes. Can you have a look?

FlorianRappl · 2025-11-19T08:29:42Z

$> dotnet publish ./FotoManager/FotoManager.csproj -p:PublishProfile=win-x64
Restore complete (4,2s)
  FotoManagerLogic succeeded (0,2s) → FotoManagerLogic\bin\Release\net9.0\FotoManagerLogic.dll
  FotoManager failed with 1 error(s) (13,0s) → FotoManager\publish\Release\net9.0\win-x64\bin\
    C:\Users\Hans\.nuget\packages\electronnet.core\0.2.0-pre.262\build\ElectronNET.LateImport.targets(430,7): error MSB4184: The expression "[System.IO.Path]::GetFullPath('')" cannot be evaluated. The path is empty. (Parameter 'path')

Build failed with 1 error(s) in 26,1s

Workload updates are available. Run `dotnet workload list` for more information.
$> more .\FotoManager\FotoManager.csproj
<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <Authors>mu88</Authors>
    <Copyright>Copyright c $([System.DateTime]::Now.ToString('yyyy'))</Copyright>
    <RuntimeIdentifier>win-x64</RuntimeIdentifier>
    <NoWarn>CA1416</NoWarn>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="ElectronNET.Core" Version="0.2.0-pre.262"/>
    <PackageReference Include="ElectronNET.Core.AspNet" Version="0.2.0-pre.262"/>
    <PackageReference Include="System.Drawing.Common" Version="9.0.8"/>
  </ItemGroup>
  <ItemGroup>
    <ProjectReference Include="..\FotoManagerLogic\FotoManagerLogic.csproj"/>
  </ItemGroup>
  <ItemGroup>
    <Compile Remove="publish\**"/>
    <Content Remove="publish\**"/>
    <EmbeddedResource Remove="publish\**"/>
    <None Remove="publish\**"/>
    <_ContentIncludedByDefault Remove="publish\**"/>
    <None Update="assets\Icon.ico">
      <CopyToOutputDirectory>Always</CopyToOutputDirectory>
    </None>
    <Folder Include="assets\"/>
    <Folder Include="wwwroot\"/>
  </ItemGroup>
</Project>

softworkz · 2025-11-19T08:46:58Z

Yup, will check

softworkz · 2025-11-19T10:45:26Z

Alright, in that project (https://github.com/mu88/BlazorFotoManager), the publish config in .pubxml is wrong. Should just copy ours.

Also, the electron-builder.json had a lot of things it should not have. I think we need to better document the migration. I thought it would be fine to say they need to copy the "build" subtree from package.json, but we also need to explain what needs to be removed.
(or maybe even add checks for things that should not be there)

Here's a fixed version of the foto manager which publishes fine with our latest packages: https://github.com/softworkz/BlazorFotoManager/tree/fix_electronnet

softworkz · 2025-11-19T11:09:59Z

To be more specific: The publish profile in this project was wither copied from our console test app or from another non-WebSDK project. These are using PublishDir and PublishProtocol, but the publishing for WebSDK projects used PublishURL - that's why it was empty and it seemed you could fix it by setting PublishURL to PublishDir.

The logic in the LateImport.targets file is admittedly hard to follow. A prerequisite for that is to know which targets are run for one or the other publishing method and which run in both cases. And the order of execution. Then it's pretty easy to understand :-)

FlorianRappl · 2025-11-19T12:23:51Z

Yeah I assumed already its outdated / wrong, but I think we should handle this case better.

For instance, if a specific variable is not set we should actually error out and print a good message. Otherwise, more people might fall into that trap (e.g., during their migration).

Example: Should we check if PublishDir is non-empty? If it is, we could error out / tell the user that the publish profile seems odd.

softworkz · 2025-11-19T12:46:20Z

Example: Should we check if PublishDir

Yes, absolutely but only in the case of WebSDK publishing. Somewhere there's a variable being set whether it's WebSDK or not. That would be the condition.
But the above is not a migration issue.

Migration issues would be about electron-builder.json. There we need to check for all folder-related values to make sure none are specified.

softworkz · 2025-11-19T12:53:43Z

Migration issues would be about electron-builder.json. There we need to check for all folder-related values to make sure none are specified.

Especially everything with relative parent paths like "..\asd...". It's very tempting to do so for getting something from the project, but this will blow up as soon as the built output is going to a different folder - like when publishing.

So the pattern is always like:

When you want to reference something in the project (from electron-builder.json)
Make sure it's copied to the build output
Then reference it with a path relative to the build output

markatosi · 2025-11-19T21:54:18Z

I attempted publishing on my mac and I saw similar behavior so this is not windows specific. (I'm using 0.2) It didn't create an infinite number of sub directories... it's stops eventually when the app bundle file has zero bytes. The top level folder where the first bundle lives is about 4 times as big as it should be. If you descend into the next directory the bundle is slightly smaller and so on and on and on. The interesting thing is the top level app bundle runs as you would expect.

if i just build a release version and run electron-builder manually from the command line it works the way it's supposed to.

softworkz · 2025-11-19T21:59:26Z

@markatosi - please check out my commit here: mu88/BlazorFotoManager@main...softworkz:BlazorFotoManager:fix_electronnet to see how I fixed that other project.

markatosi · 2025-11-19T22:04:02Z

Thank you. I'll check it out in a bit, time for lunch :-) I'll let you know if it resolves my issue soon.

No luck so far... I'm going to create a mostly empty blazor app and try and get this working instead of using a copy of my real app to make sure there isn't something else going on.

markatosi · 2025-11-20T01:20:13Z

The bare bones demo app published perfectly.
I used the same publish profile xml and electron-builder plus my custom package.json.

On my production app i removed the bin and obj directories. That did nothing.
Deleted the node_modules folder. Now publishing works.

I need a beer.

It's always the most obvious thing that i ignore

Copilot AI review requested due to automatic review settings November 18, 2025 21:47

Copilot AI reviewed Nov 18, 2025

View reviewed changes

softworkz changed the title ~~Move PR comment creation to separate workflow on:pull_request_target~~ electron-builder: Provide correct output path Nov 18, 2025

softworkz force-pushed the submit_outpath branch from 0dd97c4 to 9bb6454 Compare November 18, 2025 21:52

FlorianRappl reviewed Nov 18, 2025

View reviewed changes

softworkz force-pushed the submit_outpath branch from 9bb6454 to 4aaf736 Compare November 19, 2025 01:01

softworkz commented Nov 19, 2025

View reviewed changes

src/ElectronNET/build/ElectronNET.LateImport.targets Show resolved Hide resolved

electron-builder: Provide correct output path and fix publish url

d05191d

softworkz force-pushed the submit_outpath branch from 4aaf736 to d05191d Compare November 19, 2025 01:05

FlorianRappl approved these changes Nov 19, 2025

View reviewed changes

FlorianRappl merged commit 9b4e0e4 into ElectronNET:develop Nov 19, 2025
6 checks passed

FlorianRappl mentioned this pull request Nov 19, 2025

Broken build after migration: error MSB4184: The expression "[System.IO.Path]::GetFullPath('')" #900

Closed

Uh oh!

electron-builder: Provide correct output path #942

electron-builder: Provide correct output path #942

Uh oh!

Conversation

softworkz commented Nov 18, 2025

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Uh oh!

softworkz commented Nov 18, 2025

Uh oh!

FlorianRappl Nov 18, 2025

Choose a reason for hiding this comment

Uh oh!

softworkz Nov 19, 2025

Choose a reason for hiding this comment

Uh oh!

softworkz Nov 19, 2025

Choose a reason for hiding this comment

Uh oh!

FlorianRappl Nov 19, 2025

Choose a reason for hiding this comment

Uh oh!

FlorianRappl Nov 19, 2025

Choose a reason for hiding this comment

Uh oh!

softworkz Nov 19, 2025

Choose a reason for hiding this comment

Uh oh!

FlorianRappl Nov 19, 2025

Choose a reason for hiding this comment

Uh oh!

FlorianRappl commented Nov 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

softworkz commented Nov 19, 2025

Uh oh!

softworkz commented Nov 19, 2025

Uh oh!

softworkz commented Nov 19, 2025

Uh oh!

FlorianRappl commented Nov 19, 2025

Uh oh!

softworkz commented Nov 19, 2025

Uh oh!

FlorianRappl commented Nov 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

softworkz commented Nov 19, 2025

Uh oh!

FlorianRappl commented Nov 19, 2025

Uh oh!

softworkz commented Nov 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

softworkz commented Nov 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

softworkz commented Nov 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Update

Uh oh!

FlorianRappl commented Nov 19, 2025

Uh oh!

FlorianRappl commented Nov 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

softworkz commented Nov 19, 2025

Uh oh!

softworkz commented Nov 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

softworkz commented Nov 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

FlorianRappl commented Nov 19, 2025

FlorianRappl commented Nov 19, 2025 •

edited

Loading

FlorianRappl commented Nov 19, 2025 •

edited

Loading

softworkz commented Nov 19, 2025 •

edited

Loading

softworkz commented Nov 19, 2025 •

edited

Loading

softworkz commented Nov 19, 2025 •

edited

Loading

FlorianRappl commented Nov 19, 2025 •

edited

Loading

softworkz commented Nov 19, 2025 •

edited

Loading

softworkz commented Nov 19, 2025 •

edited

Loading

softworkz commented Nov 19, 2025 •

edited

Loading

markatosi commented Nov 19, 2025 •

edited

Loading

markatosi commented Nov 20, 2025 •

edited

Loading