feat: optimizing shortcut creation/remove

[damonyu666]

Background: Our enterprise users have reported an issue during the installation of our app. Although the application installs successfully, users cannot find shortcuts on both the desktop and the start menu.

Root Cause: The user's start menu folder is redirected to a shared path within the client's company, and no one has permission to write to this directory. Due to the write exception on the start menu, the program exits, skipping the creation of shortcuts on the desktop folder.

Expectation: In the event of a failure to create shortcuts on the start menu, the process should proceed to create shortcuts on the desktop, rather than exiting immediately.

Solution: Adding error handling for creating/deleting shortcuts, just log the exception and continue to create/delete the next shortcut.

[damonyu666]

Hi @anaisbetts, could you please help review this PR? Thank you!

[anaisbetts]

If you want to handle this special case, you should make your application Squirrel-aware and explicitly code how you want shortcuts to be created. While I appreciate the well-written description and the PR, I don't think we should change global behavior for this

[damonyu666]

@anaisbetts, our app is a Squirrel-aware Electron app. During the handling of the 'squirrel-install' event, we invoke 'update.exe' to create shortcuts. I believe there's room for improvement in the shortcut creation process within Squirrel. If creation fails at one location, it should proceed to the next one. This way, users are more likely to see a functional shortcut, rather than being frustrated by the absence of any shortcut. Therefore, wouldn't it be better to make direct modifications to Squirrel? This could benefit both developers using Squirrel and the end-users of the app.

[anaisbetts]

@damonyu666 In that case in the short term, I would just invoke the shortcut creation twice, once with just Desktop and once with just Start Menu

In general, I'm hesitant to try to cater to installations that are so broken like this - redirecting the Start Menu to a read-only shared folder just isn't a Reasonable thing that anyone should do

[damonyu666]

@anaisbetts, regarding the behavior of redirecting the start menu, I agree with your perspective. However, this is a requirement from enterprise IT that we cannot interfere with. As providers of the product, our goal is to work around such situations as much as possible. In this particular case, the best we can do is ensure users have a desktop shortcut, so they at least have a visible and accessible way to open the app. It's better than having no idea where the app is installed and how to open it, especially when the app is already installed.

Certainly, we could follow your suggestion to invoke 'update' twice to create different shortcuts. However, I believe it would be more beneficial if Squirrel could support a more tolerant approach to shortcut creation. What are your thoughts on this?

[anaisbetts]

My thoughts are the same as before:

In general, I'm hesitant to try to cater to installations that are so broken like this - redirecting the Start Menu to a read-only shared folder just isn't a Reasonable thing that anyone should do