Avoid adding a new windows firewall exemption every time an application is updated

[peters]

The problem is that every time an application is updated, the user has to add (accept) a new firewall exemption. This is probably fine for most users, but this application is running in a unattended mode (Corporate 💵 ).

I have two ideas on how we can get around this "limitation". Upon first install an exemption will have to be accepted by the user (Windows default prompt anyways):

1 - Host the CLR inside a stub executable and load the target application into memory. This would be a opt-in feature during releasify and only work for managed applications.

2 - Use .exe.config trickery rewriting the DLL load path (only works for managed dlls), modify environment "PATH" variable to include "app-X.X.X" (native dlls) and set current directory to "app-X.X.X" (I have yet to confirm this would work as expected, but I imagine so 🤞 )

@paulcbetts What are your thoughts on the matter? Am I´m overthinking this? Feedback appreciated 🍻

[anaisbetts]

@peters Are you using the latest version of Squirrel.Windows and launching via the execution stubs? I want to confirm the current Best Practice approach doesn't work. If not, Plan 2 might work, or we can try:

3 - Explicitly add app-X.X.X to the LoadLibrary path, then call LoadLibrary on ThatExe.exe and call into the import with ordinal zero which is guaranteed to be their version of main(). That might Get Weird though because we're not launching them into a pristine environment, we're launching them into one where msvcrt is already initialized etc etc etc.

[peters]

@paulcbetts Yes, I'm using the latest version. Tested on Windows 10 Pro/Enterprise (Anniversary / Creators Update). Firewall occur just after the CreateProcess call. I haven't tested any older Windows versions.

If not, Plan 2 might work

How about the following (Mix of plan 2 and 3):

1. Copy %LOCALAPPDATA%\sample\app-X.X.X\sample.exe to %LOCALAPPDATA%\sample\sample.exe
2. Copy %LOCALAPPDATA%\sample\app-X.X.X\sample.exe.config (If it exists) to %LOCALAPPDATA%\sample\sample.exe
3. Create/Modify %LOCALAPPDATA%\sample\app-X.X.X\sample.exe.config with the following:

<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <probing privatePath="app-X.X.X;any;sections;copied;from;existing;exec;config" />
    </assemblyBinding>
  </runtime>
</configuration>

4. LoadLibrary approach

Caveats:

What is the catch in all this? All your globals are initialized within the context of another thread, and >not the main one. If initializing global stuff must be in the main thread, then you can have your >WinMain call again your own callback and never return; and then return execution from that callback.

You also run the risk of calling WinMainCRTStartup() twice (the first was from your own executable) in >the same address space. Are there any side effects? Who knows

This is a lot of work though 😢

5. Alternative approach to LoadLibrary: Signal the target executable by introducing a new CLI argument; squirrel-cwd=%LOCALAPPDATA%\app-X.X.X and require target application to change their current working directory.

[jonathanbp]

Any new developments on getting this fixed?

[anaisbetts]

Nobody is working on this afaik, if you have any good ideas / insider info on how to convince the Firewall that our app is The Same App, we'd definitely take a PR to fix this bug

[jonoomph]

Just curious if there are any updates to this ticket? Any known workarounds for the Firewall prompt on every update? Thanks!

[rrhornback]

Any progress or updates to report?

[sandeep1995]

We are still stuck on this issue. @shiftkey Can you take a look at this please?

[sandeep1995]

Do we have a solution for this yet?

[SultanaJon]

Any update on this?

[Rambarani]

@peters I also facing this issue. did you able to fix this ?

[SultanaJon]

@Rambarani I don't this this is fixed. Microsoft Teams fixed this by creating a previous and current directory where their previously used version will live and their current (new) version will live. This allows them to add an allowed firewall exception to the exe in the current directory and allows their app to work when updated.

[caesay]

This has been fixed in my Squirrel fork (tracked in clowd#24) by following a similar approach to how msft teams did it with their proprietary fork. This solved loads of issues, tray icon pinning, firewall rules, gpu affinity, taskbar pinned shortcuts, etc. It will be released in v3.0 (eta early June).

[Rambarani]

@Rambarani I don't this this is fixed. Microsoft Teams fixed this by creating a previous and current directory where their previously used version will live and their current (new) version will live. This allows them to add an allowed firewall exception to the exe in the current directory and allows their app to work when updated.

Thanks @SultanaJon

[Rambarani]

This has been fixed in my Squirrel fork (tracked in clowd#24) by following a similar approach to how msft teams did it with their proprietary fork. This solved loads of issues, tray icon pinning, firewall rules, gpu affinity, taskbar pinned shortcuts, etc. It will be released in v3.0 (eta early June).

Thanks @caesay