OSX Processes not closing #420

New Issue

claunia · 2026-01-29T16:39:06Z

claunia commented

2026-01-29 16:39:06 +00:00

Originally created by @christosk92 on GitHub (Dec 4, 2019).

Originally assigned to: @robertmuehsig on GitHub.

Related to issue #226 and #68 but #68 was never solved and the solution proposed in #226 doesn't work.

Version:
Electron.NET API version: v7.30.2
Electron.NET CLI version: v7.30.2

.NET CORE: 3.0
NPM: 6.12.0

Target:
macOS Mojave

When an app on macOS is closed, its child processes still remain active and have to be killed through the activity monitor. At first I thought this was related to an issue in my code but this issue also exists on the demo projects you provide.

Steps to Reproduce:

Build latest demo project on macOS
Run
Close the app

Originally created by @christosk92 on GitHub (Dec 4, 2019). Originally assigned to: @robertmuehsig on GitHub. Related to issue #226 and #68 but #68 was never solved and the solution proposed in #226 doesn't work. * **Version**: Electron.NET API version: v7.30.2 Electron.NET CLI version: v7.30.2 .NET CORE: 3.0 NPM: 6.12.0 * **Target**: macOS Mojave When an app on macOS is closed, its child processes still remain active and have to be killed through the activity monitor. At first I thought this was related to an issue in my code but this issue also exists on the demo projects you provide. Steps to Reproduce: 1. Build latest demo project on macOS 2. Run 3. Close the app

claunia added the help wanted bug labels 2026-01-29 16:39:06 +00:00

claunia closed this issue

2026-01-29 16:39:07 +00:00

claunia commented

2026-01-29 16:39:08 +00:00

@mpnow commented on GitHub (Dec 18, 2019):

FYI I'm seeing this same behavior on my small test app. Almost the same environment (latest Electron.NET 7.30.2) but I'm on .NET Core 3.1 and macOS Catalina.

@mpnow commented on GitHub (Dec 18, 2019): FYI I'm seeing this same behavior on my small test app. Almost the same environment (latest Electron.NET 7.30.2) but I'm on .NET Core 3.1 and macOS Catalina.

claunia commented

2026-01-29 16:39:08 +00:00

@GregorBiswanger commented on GitHub (May 10, 2020):

I have no Mac and @robertmuehsig have no time.

We need help for this issue please.

@GregorBiswanger commented on GitHub (May 10, 2020): I have no Mac and @robertmuehsig have no time. We need help for this issue please.

claunia commented

2026-01-29 16:39:09 +00:00

@mpnow commented on GitHub (May 10, 2020):

I have no Mac

@GregorBiswanger I have a spare MacBook Pro I could send you if no one is available to help out with this issue. Interested?

It's really critical for this bug to be resolved in order to make a working Electron.NET-based Mac app.

@mpnow commented on GitHub (May 10, 2020): > I have no Mac @GregorBiswanger I have a spare MacBook Pro I could send you if no one is available to help out with this issue. Interested? It's really critical for this bug to be resolved in order to make a working Electron.NET-based Mac app.

claunia commented

2026-01-29 16:39:09 +00:00

@GregorBiswanger commented on GitHub (May 11, 2020):

@mpnow Sounds good! Then I can definitely provide the support for it better... so far no one has reported...

@GregorBiswanger commented on GitHub (May 11, 2020): @mpnow Sounds good! Then I can definitely provide the support for it better... so far no one has reported...

claunia commented

2026-01-29 16:39:09 +00:00

@dafergu2 commented on GitHub (May 18, 2020):

@mpnow I'm currently looking at it. My main dev system is a mac, so I'm going to try and get a lot of things mac related fixed up and improved.

@dafergu2 commented on GitHub (May 18, 2020): @mpnow I'm currently looking at it. My main dev system is a mac, so I'm going to try and get a lot of things mac related fixed up and improved.

claunia commented

2026-01-29 16:39:10 +00:00

@brianmed commented on GitHub (May 18, 2020):

The code below looks like it's working for me. I only have one app window, and when I close it, all processes are gone. In addition, when I quit the app via the Dock, then all processes are gone. Hope it continues working and works for you.

This is in the ElectronBootstrap function in my Startup.cs file.

            browserWindow.OnClosed += () =>
            {
                Electron.App.Exit(0);

                Environment.Exit(0);
            };

@brianmed commented on GitHub (May 18, 2020): The code below looks like it's working for me. I only have one app window, and when I close it, all processes are gone. In addition, when I quit the app via the Dock, then all processes are gone. Hope it continues working and works for you. This is in the ElectronBootstrap function in my Startup.cs file. ``` browserWindow.OnClosed += () => { Electron.App.Exit(0); Environment.Exit(0); }; ```

claunia commented

2026-01-29 16:39:10 +00:00

@dafergu2 commented on GitHub (May 18, 2020):

One thing I've noticed is that the app all windows closed event is not being triggered. In order to keep this as much in line with recommendations on raw Electron, I was planning on making sure that event gets bubbled up. What's interesting is that you are also calling Environment.Exit(). If you remove that line, does the .net core project stay running?

@dafergu2 commented on GitHub (May 18, 2020): One thing I've noticed is that the app all windows closed event is not being triggered. In order to keep this as much in line with recommendations on raw Electron, I was planning on making sure that event gets bubbled up. What's interesting is that you are also calling `Environment.Exit()`. If you remove that line, does the .net core project stay running?

claunia commented

2026-01-29 16:39:10 +00:00

@brianmed commented on GitHub (May 18, 2020):

Could event issue be this code in app.js?

There's a lot of code, and I'm not sure this is executed, but if so, looks like could be related to darwin issues.

    app.on('window-all-closed', () => {
        // On macOS it is common for applications and their menu bar
        // to stay active until the user quits explicitly with Cmd + Q
        if (process.platform !== 'darwin' &&
            isQuitWindowAllClosed) {
            app.quit();
        }
    });

@brianmed commented on GitHub (May 18, 2020): Could event issue be this code in app.js? There's a lot of code, and I'm not sure this is executed, but if so, looks like could be related to darwin issues. ``` app.on('window-all-closed', () => { // On macOS it is common for applications and their menu bar // to stay active until the user quits explicitly with Cmd + Q if (process.platform !== 'darwin' && isQuitWindowAllClosed) { app.quit(); } }); ```

claunia commented

2026-01-29 16:39:10 +00:00

@brianmed commented on GitHub (May 18, 2020):

Correct, if the Environment.Exit() line is removed, then the .Net Core project stays running.

@brianmed commented on GitHub (May 18, 2020): Correct, if the Environment.Exit() line is removed, then the .Net Core project stays running.

claunia commented

2026-01-29 16:39:11 +00:00

@dafergu2 commented on GitHub (May 18, 2020):

Could event issue be this code in app.js?

There's a lot of code, and I'm not sure this is executed, but if so, looks like could be related to darwin issues.
    app.on('window-all-closed', () => {
        // On macOS it is common for applications and their menu bar
        // to stay active until the user quits explicitly with Cmd + Q
        if (process.platform !== 'darwin' &&
            isQuitWindowAllClosed) {
            app.quit();
        }
    });

I believe so. If you look down, there's another call to app.on('window-all-closed'...) which actually emits the event back to the .net process. I'm going to restructure that shortly.

@dafergu2 commented on GitHub (May 18, 2020): > Could event issue be this code in app.js? > > There's a lot of code, and I'm not sure this is executed, but if so, looks like could be related to darwin issues. > > ``` > app.on('window-all-closed', () => { > // On macOS it is common for applications and their menu bar > // to stay active until the user quits explicitly with Cmd + Q > if (process.platform !== 'darwin' && > isQuitWindowAllClosed) { > app.quit(); > } > }); > ``` I believe so. If you look down, there's another call to `app.on('window-all-closed'...)` which actually emits the event back to the .net process. I'm going to restructure that shortly.

claunia commented

2026-01-29 16:39:11 +00:00

@dafergu2 commented on GitHub (May 18, 2020):

Correct, if the Environment.Exit() line is removed, then the .Net Core project stays running.

Thanks! That tells me that the electron process should also kill the .net core http server process when it exits as well. I'll see about fixing that and push up a PR.

@dafergu2 commented on GitHub (May 18, 2020): > Correct, if the Environment.Exit() line is removed, then the .Net Core project stays running. Thanks! That tells me that the electron process should also kill the .net core http server process when it exits as well. I'll see about fixing that and push up a PR.

claunia commented

2026-01-29 16:39:11 +00:00

@mpnow commented on GitHub (May 18, 2020):

That sounds like good news, guys, thanks.

I'm also shipping an extra Mac I had to @GregorBiswanger so going forward he'll be in better shape to work on and test on MacOS.

@mpnow commented on GitHub (May 18, 2020): That sounds like good news, guys, thanks. I'm also shipping an extra Mac I had to @GregorBiswanger so going forward he'll be in better shape to work on and test on MacOS.

claunia commented

2026-01-29 16:39:12 +00:00

@dafergu2 commented on GitHub (May 18, 2020):

I have a fix that is working for me, but I don't think it is the ideal way to handle it. There's a mix of logic between the electron main process code and the .net api code. I think it would be better to pull all of the logic up to the .net api code so that it:

Simplifies the logic in the electron main process (which, imo, is harder to debug)
AND
Allows the end user of ElectronNET to explicitly control all behavior which isn't really the case right now.

@GregorBiswanger I'll go ahead and commit this and push it up to my fork. I haven't had time to test on Windows and Linux, though. Based on the changes, it shouldn't be impactful, but we'd probably still want to test it.

@dafergu2 commented on GitHub (May 18, 2020): I have a fix that is working for me, but I don't think it is the ideal way to handle it. There's a mix of logic between the electron main process code and the .net api code. I think it would be better to pull all of the logic up to the .net api code so that it: 1) Simplifies the logic in the electron main process (which, imo, is harder to debug) **AND** 2) Allows the end user of ElectronNET to explicitly control all behavior which isn't really the case right now. @GregorBiswanger I'll go ahead and commit this and push it up to my fork. I haven't had time to test on Windows and Linux, though. Based on the changes, it shouldn't be impactful, but we'd probably still want to test it.

claunia commented

2026-01-29 16:39:12 +00:00

@christosk92 commented on GitHub (May 18, 2020):

Awesome to hear guys! My mac recently broke so I haven't gotten around to try it yet.

@christosk92 commented on GitHub (May 18, 2020): Awesome to hear guys! My mac recently broke so I haven't gotten around to try it yet.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/Electron.NET#420