Squirrel.windows: Could someone please elaborate on how machine wide installs are supposed to work?

[provkristian]

I have referred to machine-wide-installs.md but am not making much progress yet with creating a successful machine wide installer. I'm not sure if this is a bug or a mistake on my part. Thanks.

Actual: After running setup.msi, logging out and back in with the current user on Windows 8, the application is not installed to %localappdata% . The setup.msi appears to run from UI that is briefly display (I accepted the UAC dialog).

Expected: From reading the documentation, I'm assuming that the app should be installed.

Repro steps:
1) create nuget package (from nuget -pack command) -> output UserInterfaceApp.1.0.5855.30430.nupkg
2) run releasify from CI powershell
.packagessquirrel.windows.1.2.1toolsSquirrel.exe --shortcut-locations='Startup' --releasify $package.name (copied to S3 afterward)
3) download files from S3 bucket to a local folder on the desktop (%userprofile%desktoptest) and make sure to unblock the .exe and .msi from the properties dialog)
RELEASES
Setup.exe
Setup.msi
UserInterfaceApp-1.0.5855.30430-full.nupkg
4) from a non-admin command prompt:
cd %userprofile%desktoptest
Setup.msi

Notes:
There are no errors in the eventvwr. There is no new entry at HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionRun after running setup.msi.
This is a SquirrelAware app using SquirrelAwareApp.HandleEvents(); to avoid the default behavior of creating shortcuts.

[skaryshev]

Please take a look at https://github.com/Squirrel/Squirrel.Windows/issues/508 There is a patch and a fix on similar issues. Hope it helps.

[provkristian]

@skaryshev Thanks but I believe that this is a different issue. The setup.msi runs but when the user logs out and logs in again the application is not installed. There are no errors in the event log and no registry entry either.

[anaisbetts]

There is no new entry at HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionRun

Check Wow6432Node. Also, do you have a SquirrelSetup.log?

[provkristian]

There is a HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoftWindowsCurrentVersionRun entry with a value of %ProgramFiles% InstallerUserInterfaceApp.exe --checkInstall . I noticed that the installer is placed in ProgramFiles(x86) though.

I think that there might be two bugs with the registry value. 1) there's a space in the path and 2) the msi puts the installer under C:Program Files (x86)Installer since it's a 32 bit app.

If I manually created a copy of the installer under %ProgramFiles%Installer it worked. Thanks.

[anaisbetts]

Huh, interesting. Thanks for the tip, we'll look into it

[provkristian]

@paulcbetts Thanks! Unfortunately, for our app since we use CefSharp we need to choose x86 or x64. We chose x86 to be conservative for it working on various PCs.

Please let us know if there's anything that we can do to help. Perhaps after we get more familiar with the code we could help with pull requests.

I'm not sure if what I mentioned above for issue 1 is really an issue. Maybe the code is already handling the space. For issue 2, I'm not sure if you would want a dependency on a tool like dumpbin for determining if an app is x86 or x64 (dumpbin /headers | findstr "machine") or if there's a way to read the "PE L" type entry from the binary?? Thanks. Cheers.

[anaisbetts]

@provkristian So, whether or not your _app_ is 64-bit, the installer itself is always 32-bit. You can install 64-bit apps with a 32-bit installer without a problem

[provkristian]

@paulcbetts Thanks. I agree about the installer. The issue that we're seeing is that the registry entry that the Squirrel created MSI create points to %ProgramFiles% InstallerUserInterfaceApp.exe --checkInstall but the file is actually copied to %ProgramFiles(x86)%Installer . We can use Powershell to workaround it if we need to but would rather not if possible.

[anaisbetts]

@provkristian No that's definitely a bug, I'll see what I can do

[provkristian]

@paulcbetts Okay, thank you. By the way, is there an organization behind Squirrel or is it supported by donations or anything?

[anaisbetts]

@provkristian No donations, it's free :)

[provkristian]

@paulcbetts Great. Thanks again. I work for a non-profit so free is helpful.

[provkristian]

Good morning, I'm not sure how the triage process works for Squirrel. Is there an ETA for the fix? We're tentatively planning to use Powershell instead for fresh machine install. Thanks.

[provkristian]

Good morning,
FYI to others struggling with machine installs. It's essentially broken for our use case (machine install an app that is launched at startup) because of this issue and another (not sure if it's logged yet) where it doesn't launch the process with the proper working directory. It seems strange that Squirrel assumes that people want an app launched after install and does not give them an option to easily disable that.

Here's a simple workaround using powershell (pseudocode, I could try to share more if I have time):
1) Unblock (assuming you're downloading from S3 or Azure Blob storage or something) and run setup.exe (using --silent)
2) Copy Squirrel generated files to ProgramData folder (from the app data local folder)
3) Delete Squirrel generated files in app data local and programdata
4) Deleting Squirrel generated registry entry in HKLM:SOFTWAREWow6432NodeMicrosoftWindowsCurrentVersionRun (be careful here) or equivalent (if 32 bit machine)
5) Unblock a shortcut to your app that points to the programdata subfolder and copy to Startup folder $env:ProgramDataMicrosoftWindowsStart MenuProgramsStartUp
6) optionally invoke item for the shortcut

I'm sharing so it's hopefully useful to others and perhaps food for thought when fixing the Squirrel issues (maybe I could help if I have time). Note: this should allow auto-update to work fine if your config entries are properly setup. Thanks.
-Kristian

[DenisPitcher]

I'm encountering the same bug. As mentioned above, the registry key entry points to %ProgramFiles% when it should point to %ProgramFiles(x86)%

As a temporary fix I just added a registry file to be run that changes the registry entry value to the correct location.

[fburr]

I am having this issue as well with the new version 1.2.4.0 is a fix coming for this? Or should we just find a work around?

[anaisbetts]

This doesn't repro for me at all, MSIs work on 64-bit, can someone send me an MSI that doesn't work?

[fburr]

Uploading Setup.zip…
The issue am having is the path in the registry key is incorrect it reads

%ProgramFiles% InstallerDU.exe --checkInstall (wrong directory and a space before installer)

If i change it to "C:Program Files (x86)InstallerDU.exe" it works great.
I am going to download MyApp and see if i can recreate the issue and send you the MSI

[anaisbetts]

Can you also post your nuspec file? I think you're having problems because your nuspec file is incorrect. There's supposed to be a product name in that name, not Installer

[fburr]

MyApp.2.5.4.zip

[anaisbetts]

@fburr Fill out Id, Title, and Description with real entries

[fburr]

Will do.

[fburr]

I have filled out those fields. The new value for the reg key is
%ProgramFiles%MyApplication InstallerMyApp.exe --checkInstall

The exe is located at C:Program Files (x86)InstallerMyApp.exe
MyAppFburr.zip

[anaisbetts]

@fburr Are you building on a 32-bit machine and installing on a 64-bit machine?

[fburr]

I am building and installing on a 64bit machine.

[provkristian]

I'm not sure how the context on this was lost. This is still considered a bug, correct?
"paulcbetts commented on Jan 14
@provkristian No that's definitely a bug, I'll see what I can do".

[anaisbetts]

I'm not so sure now, if only because I can't repro it on any of the installers I'm building

[provkristian]

Hmm... I wonder if you built an example app that uses CefSharp targeting x86 if you'd see it. Thanks.

[provkristian]

I could try to get logs, screenshots, etc... when I have time from one of our apps that has this issue if you'd like. Thanks.

[anaisbetts]

@provkristian The NuSpec file and MSI file would help

[provkristian]

@paulcbetts Thanks. Can I email a link to you for the .MSI and NuSpec?

[anaisbetts]

Sure

[provkristian]

Thanks. I just sent one to the email in your profile.

[qubicle]

Is there a final solution for this problem?
I'm facing the same problem with the generated MSI.

[erenalbayrak]

I have the same problem. Not able to install machine wide for all users. Neither by re-login and reboot after executing Setup.msi or execute Setup.exe with --machine flag.
Have someone a solution?

[erenalbayrak]

Ok, finally I was able to install the App "machine wide".
Actually not really machine wide because it will installed in every users %localappdata%

At first I uninstalled the App which was installed via Setup.exe previous.
Than I installed the App with Setup.msi
Now after a re-login the App should install himself and create a shortcut. If not, (now this is important) go to %localappdata% and delete the directory of your application. In this directory just 2 files placed: Update.exe and .dead
Finally re-login again and our application will install automatically in %localappdata%

[kristianjaeger]

@Kff7 @qubicle I have listed a workaround above (from my provkristian account). I don't know what the long term plans are for this issue. Cheers.

[hvassbotn]

@paulcbetts We are also badly bitten by this problem. I think I know what the reason is - we also include the CEF (Chromium) binaries, and while all other .exes and .dlls are 32-bit, there is one 64-bit exe in there: wow_helper.exe.

I think this trips up Squirrel so that it creates the wrong (64-bit) value in the registry:

HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoftWindowsCurrentVersionRun
OntradeMachineInstaller=%ProgramFiles%Infront InstallerOntrade.exe --checkInstall

Notice it uses %ProgramFiles%

It should have used %ProgramFiles(x86)%

Is there any way of overriding this?

I'll experiment with making an installer without the wow_helper.exe, not sure how Chromium will react if this is missing...

[hvassbotn]

Looks like wow_helper.exe is only needed if you

• Run on Vista or earlier
• Need to support Sandboxing

https://bitbucket.org/chromiumembedded/cef/issues/1915/remove-wow_helperexe-in-2704-branch-and

This is not the case for us, so we'll be dropping that .exe from the installer. Hopefully that will workaround the Squirrel msi bug.

[hvassbotn]

Unfortunately, that didn't help :(

%ProgramFiles%Infront InstallerOntrade.exe --checkInstall

[kristianjaeger]

@hvassbotn There is a workaround above from my provkristian account that might work for you. We also use CEF or CefSharp in our case.

[hvassbotn]

@kristianjaeger Thanks, but that means everyone has to actually write that script. It is also very unclear how to do that. Seems like the steps have some bugs, too (like delete from ProgramData just after copying files there..?).

@paulcbetts Anyway, I think I located the location that causes the bug. In the squirrel.windowsvendorwixtemplate.wxs file, line 28:

<DirectoryRef Id="TARGETDIR">
  <Component Id="RegistryEntries" Guid="{{IdAsGuid3}}">
    <RegistryKey Root="HKLM" Key="SOFTWARE\Microsoft\Windows\CurrentVersion\Run">
      <RegistryValue Type="expandable" Name="{{Id}}MachineInstaller" Value="%ProgramFiles%\{{Title}} Installer\{{Id}}.exe --checkInstall" />
    </RegistryKey>
  </Component>
</DirectoryRef>

Here it looks like the %ProgramFiles% var is hard-coded...

Hm, looks like this file is used "live" when generating the .msi... So if I change it to %ProgramFiles(x86)% and rebuild it should hopefully work.

[hvassbotn]

According to this

http://stackoverflow.com/questions/17688758/using-programfilesx86-on-windows-os-32bit

• %Programfiles(x86)% only works on 64-bit windows
• %Programfiles% works on 32-bit windows
• %Programfiles% evaluates to different folders depending on the bitness of the running process

So if MsiExec running your .msi is 32-bit it works, evaluating to C:ProgramFiles(x86). If MsiExec running is 64-bit (which I assume is always the case/the default on a 64-bit OS?), it evaluates to C:Programfiles which is wrong if the app you're _installing_ is 32-bit (our case).

I don't have time to find an elaborate solution, so I've just made two versions of template.wxs; template32.wxs and template64.wxs that I copy into template.wxs just before generating the msi with Squirrel. Then I rename the resulting Setup.msi files accordingly so that I end up with two: Setup32.msi (for 32-bit OSes) and Setup.msi (for 64.but OSes).

Not ideal, but then at least we have something that will actually work. Most companies have all PCs 32-bit or 64-bit so they just need to select the right one.

[kristianjaeger]

@hvassbotn You could submit a pull request if you have a fix for this. The PowerShell workaround is something that I did at work, and it works. I would need approval to share the code though. Best of luck.

[hvassbotn]

@kristianjaeger I see. I don't have a clean solution that could be implemented in a pull request.

What I did was to make two versions of the .wxs file as mentioned above and then invoke Squirrel twice.

The batch file I use to do this looks like this (removed only some local specifics - you would need to modify to match your local folders etc):

Set nupnkfile="ontrade.7.1.%1.nupkg"
if exist %nupnkfile% (
  xcopy E:\GitWork\Apps\Squirrel.Windows\template32.wxs E:\GitWork\Apps\Squirrel.Windows\template.wxs /y
  squirrel -releasify=%nupnkfile% -g ..\common\gifs\AnimatedColorfulProgress.gif --setupIcon=ontrade_Icon.ico -n "/f XXX.pfx /p ***** /t http://timestamp.verisign.com/scripts/timstamp.dll"
  del Releases\SetupInfront32bit.msi
  ren Releases\Setup.msi SetupInfront32bit.msi
  xcopy E:\GitWork\Apps\Squirrel.Windows\template64.wxs E:\GitWork\Apps\Squirrel.Windows\template.wxs /y
  squirrel -releasify=%nupnkfile% -g ..\common\gifs\AnimatedColorfulProgress.gif --setupIcon=ontrade_Icon.ico -n "/f XXX.pfx /p ***** /t http://timestamp.verisign.com/scripts/timstamp.dll"
) else (
ECHO %nupnkfile% does not exist!
)

[anaisbetts]

This issue is almost always because you:

1. Installed the normal EXE
2. Uninstalled it
3. Installed the MSI
4. Squirrel saw that the current user uninstalled the app and is respecting their wishes to not reinstall it

To resolve this, go into %LocalAppData% and delete your app's folder completely.

I don't believe that the info above wrt 32-bit / 64-bit is correct because of WOW64 Registry redirection. Any Value of %ProgramFiles% that gets written under Wow6432Node gets transparently rewritten as %ProgramFiles(x86)%

[hvassbotn]

Thanks @paulcbetts! I just tested this now - you are absolutely right.

That explains the weirdness that it sometimes works and sometimes doesn't. This may have been discussed in issue tickets before (?), but I haven't noticed and Squirrel is a bit of black box in this regard (yes, I know - "use the source, Luke").

But may I suggest that this critical information be included here:

https://github.com/Squirrel/Squirrel.Windows/blob/master/docs/using/machine-wide-installs.md

In fact, a good deal more information should be included there. We created a tech page for admins to use for reference - we will include troubleshooting info there about the manual uninstall / delete folder tips:

http://goinfront.com/support-downloads/information-for-it-administrators/

We should include more info there - such as details about the Run registry key, the program filesinstaller.exe, that this is a renamed copy of the normal installer etc.

So should the Squirrel msi Wiki page. :)

PS: Technically the information I wrote about %ProgramFiles% is correct - what I forgot is that the key is in the WOW6432Node and thus only run by the WOW system, will always run in 32-bit mode and thus %ProgramFiles% will always resolve to the 32-bit program files folder :). The bitness of the MsiExec that just _writes_ the key does not matter.

[Thieum]

@shiftkey https://github.com/Squirrel/Squirrel.Windows/issues/555#issuecomment-253265130 appears to answer all the cases including the original question. There is also a PR #1443 that update the docs with the info. I think this can be closed.

[bifacil]

I've a similar issue.

In my case, the problem was the value in HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Run key.

Tha value was: %ProgramFiles%\ Installer\MyApp.exe --checkInstall (sic)

Notice there is a space after the first slash \

I solved the problem changing the value to:

%ProgramFiles%\Installer\MyApp.exe --checkInstall

I see now is the exact same thing that happened to @provkristian

The space character was missing because the nuspec missed the title field.

As @anaisbetts said:

You must fill out Id, Title, and Description with real entries