Shotcuts stop working after upgrading from 1.4.4 to 1.7.6

[PhilJenson]

When upgrading from 1.4.4 to 1.7.6 the shortcut links stop working. If you run the Setup.exe the shortcut links do work. It appears as if after upgrading the [app].exe file is missing from the root folder.

The purpose of Squirrel is to provide a means of updating app's automatically but there seems to be no way of updating the control itself. How do you upgrade Squirrel from v1.4.4?

[hs-hub-world]

Hi, just couple of pointers:

• Looks like there is a known issue with version 1.7.6 (please review issues section).
• Try version 1.7.5
• I am just curious. looks like you were using 10-month old code of Squirrel. How frequently do you release new code of your app -? I hope you have tested this code in Dev/Qa env before pushing to production - since you have jumped a lot of versions from 1.4.4 to 1.7.6.

regarding your questions: "The purpose of Squirrel is to provide a means of updating app's automatically but there seems to be no way of updating the control itself. How do you upgrade Squirrel from v1.4.4?"
Can you please elaborate. Because as far I know we use NuGet packages and we are able to quickly upgrade the Squrrel package if there is a new release. Are you using Nuget -?

Thanks
HS

[PhilJenson]

I have done a lot of reading since posting and now see few others have the same issue see #920

We release once every 2 weeks or less and have been trying to upgrade from 1.4.4 since 1.5.0 was released. Last week I tried version 1.5.0, 1.7.5 & 1.7.6, all have the same effect. Initially we were not too concerned as 1.4.4 works well for us, but its got to a stage where I don't like to ignore this any longer. My comments about no way of upgrading squirrel refer to the issue that upgrading from 1.4.4 to any version thereafter leave the shortcuts not working and in effect the application dead on the customers computer. Thus there is no way of upgrading squirrel 'on the customers computer'. Upgrading from 1.5.0 thereafter is not an issue.

In 1.5.0 a stub.exe was introduced and It appears that that the only way this gets put on to a customers computer is by running setup.exe. This means if you initially installed using 1.4.4 the stub.exe is missing, but later versions of Squirrel modify the shortcuts to point to the missing file, thus killing the app.

Our intention now is to continue to use 1.4.4 and in the next release copy this missing stub.exe to the root folder. Then in two months time all active users will have the missing file, and at that stage upgrade to the latest Squirrel. Any customer who does not upgrade in-between will have to reinstall using the setup.exe, but at least this way we will reduce the number of support calls complaining they can't start our app after an update.

Of cause a change to squirrel to check and install the missing stub.exe would be a better solution, after-all there is a way to replace the Update.exe. But I don't know if this is possible retrospectively or if this needed to be built into 1.4.4

[lukeskinner]

Our intention now is to continue to use 1.4.4 and in the next release copy this missing stub.exe to the root folder. Then in two months time all active users will have the missing file, and at that stage upgrade to the latest Squirrel. Any customer who does not upgrade in-between will have to reinstall using the setup.exe, but at least this way we will reduce the number of support calls complaining they can't start our app after an update.

You shouldn't have to manually create the stub as it should be included in your .nupkg created during releasify.
I would check your .nupkg that you built with 1.7.5/1.7.6. Inside the .nupkg you should see your app exe (ExampleApp.exe) and a stub (ExampleApp_ExecutionStub.exe).

If you don't see this stub exe in there then this will be the first problem. I have a post build check to ensure that there is always a execution stub in the package to be safe.

I'll make a fresh 1.4.4 app later today and give the upgrade a go.

[PhilJenson]

The [App]_ExecutionStub.exe is present in the .nupkg package. But as far as I can tell this only gets put into the root directory when Setup.exe is run, not as part of an update. Running setup.exe works fine, but we need the update to work as we can't ask all customers to reinstall.

[lukeskinner]

I tried upgrading from 1.4.4 to 1.7.6 and hit the same problem (stub is left intact in the app-{version} folder).

Going through the latest Squirrel code I can see in the ReleasePackage.cs class a method called ExtractZipForInstall which handles the stub executable installation. This exists from 1.5.0 onwards but not for anything below.

A quick fix would be to handle the onAppUpdate event in your 1.7.6 version and rename & move the stub exe up one level. I'm not sure what the real fix in Squirrel is going to be.

I haven't had time to test the rename/move works - but the code below is roughly what Squirrel what do with the stub exe.

string rootStubFilePath = Path.Combine(mgr.RootAppDirectory, Path.GetFileName(stubExeFilePath).Replace("_ExecutionStub.exe", ".exe"));

File.Move(stubExeFilePath, rootStubFilePath)

[PhilJenson]

Thanks for confirming this.

Unfortunately I don't think your solution will help as the code for copying the stub.exe (which you suggest) wont be in the released version of our code, so we will need to do a intermediate release of our app to include this, and that is what we already came up with.

Ideally what is needed is a change within Squirrel so that on next install it (not our code) copies the stub.exe to the correct place before the shortcut are modified, but (I assume) as it is the code within our existing app (which is using 1.4.4) that is doing the update this is not possible.

[lukeskinner]

If you run the 1.7.x squirrel releasify process on your application you will have a [App]_ExecutionStub.exe in your nuget package. Even though the code to move it into the correct place is not there, it will still be copied into the app-{version} folder - it unzips the whole folder.

This is a screenshot of what the app-{version} folder looks like for me after performing a 1.4.4. to 1.7.6 upgrade. The execution stub is in this folder sitting next to the real exe.

Screenshot of the root folder of the app (again after a 1.4.4 to 1.7.6 upgrade) - stub is missing

If you place the code below into your application, build it and create the squirrel package using 1.7.x it will move the stub into the correct location using the OnAppUpdate event. Once the stub is in place for the user, it will just skip over this code in future updates so it will only ever run once.

In my sample app I'm using, the shortcuts work after doing this.

                SquirrelAwareApp.HandleEvents(
                  onInitialInstall: delegate (Version v) {
                      mgr.CreateShortcutForThisExe();
                  },
                  onAppUpdate: delegate (Version v) {

                      var exeName = Path.GetFileNameWithoutExtension(Assembly.GetEntryAssembly().Location);

                      var rootDirectory = mgr.RootAppDirectory;

                      var rootStubPath = Path.Combine(rootDirectory, exeName + ".exe");

                      if (!File.Exists(rootStubPath))
                      {
                          var updateVersionFolder = Path.Combine(rootDirectory, "app-" + v.Major + "." + v.Minor + "." + v.Build);

                          if (Directory.Exists(updateVersionFolder))
                          {
                              var updateStubPath = Path.Combine(updateVersionFolder, exeName + "_ExecutionStub.exe");

                              if (File.Exists(updateStubPath))
                              {
                                  File.Move(updateStubPath, rootStubPath);
                              }
                          }
                      }
                  },
                  onAppUninstall: v => mgr.RemoveShortcutForThisExe());

Screenshot after running the upgrade from 1.4.4 to 1.7.6 using the code above.

[PhilJenson]

I am very happy to say you are correct, this is working for us now. Thanks for taking the time to investigate and explain, it has helped immensely.

[gregsdennis]

This should be handled from within squirrel. I shouldn't have to manage the shortcuts in my application. This is a bad user (the dev using the library) experience.

[JKSnd]

I agree with @gregsdennis. This is a workaround, not a fix. I've been watching this issue and a couple others as I wait to upgrade past 1.2.5. @PhilJenson what do you think about keeping this open until such a fix is brought into the library itself?

[PhilJenson]

Whilst it is a workaround it works. Adding a few lines additional code is easy, I am just grateful there is a solution. I will leave it to the judgment of those activity developing Squirrel to decide the best way forward, but clearly it would help a number of people (still on 1.4.4 or less) if this was handle within Squirrel.

[gregsdennis]

@PhilJenson I would argue that this issue needs to stay open until the fix is integrated, and should be closed only by the maintainers.

It's great that there's a workaround, but the issue remains a part of Squirrel. And until this is integrated into the library, users will have to find this issue (which is harder now that it's closed) and copy the workaround code.

Furthermore, if the fix is ever integrated, this workaround will cause failures.

[JKSnd]

Agreed. Closed issues imply that a proper fix has been realized.

[anaisbetts]

Hey all, I'm going to have a look at this soon, sorry for the difficulties. That being said, while I try to think about migration, i can't test for every possible combination of From => To, so try not to hang out on old versions of Squirrel. The updater updates itself automatically when you upgrade the lib in your app, so it's usually as easy as just making sure your project is up-to-date

[stefanolson]

@paulcbetts I'm on 1.44 also and haven't upgraded yet. Every time I look at upgrading (which is infrequent) seems to be some sort of issue with the current release so I put it off for a bit longer. Now that the 7zip code is in place I am keen to upgrade. Because the version that I have works really well, I tend to avoid upgrading until I really need to because I can't afford any sort of breakages.

[JKSnd]

@PhilJenson out of curiosity is your build script set up such that it uses whatever version of squirrel is referenced by your csproj, or is it set up to use an installed version of squirrel somewhere in the filesystem?

I've seen projects reference 1.7.x, but get releasified with 1.4.x and things got super silly super quick at install-time.

[PhilJenson]

It is using an installed version but this is the same as that within the app.

Of cause we have now implemented a solution suggested by @lukeskinner so no longer have a problem and are now using 1.7.6

[JKSnd]

I'm looking into using the same workaround code. I've been kicking it around on a sandbox project and I've noticed a gotcha.

Squirrel seems to create the app-{version} folders using the executable's AssemblyInformationalVersion, but the Version object that the squirrel event exposes only supports the executable's AssemblyVersion.

So, the if (Directory.Exists(updateVersionFolder)) check will always fail for prerelease versions that contain metadata in their versions. All in all, that's not a huge issue as long as your production releases informational versions match your assembly versions, but it would help quite a lot if the use of versions were consistent.