Gotchas when migrating from ClickOnce

[jsoldi]

This seems like a great alternative to ClickOnce. I'm just getting started using Squirrel and so far it's been great, but I've found a couple of differences with ClickOnce:

1. The fourth digit of the version number must be left at zero, otherwise, it'll break the NuGet package.
2. Settings won't be automatically copied when an update is made, this must be done programmatically.

I noticed these two just as I was getting started, so I wonder how many other differences there may be that I haven't thought of. I think it would be nice to have a comprehensive list of differences between how ClickOnce and Squirrel work (especially since ClickOnce is mentioned in the tagline), to prevent users like myself from running into trouble when it's already too late.

[sopelt]

Settings won't be automatically copied when an update is made, this must be done programmatically.

@jsoldi what do you mean by that? Are you creating a settings file relative to your executable? You should probably use (local) app data instead if that is the case.

[3milio]

I've been testing Squirrel with the same aim: migrating from Clickonce. One thing I can't find is how to check for (and apply) updates when starting the app. This is equivalent to the Clickonce option 'Before the application starts' in Visual Studio (ie, project properties -> Publish -> Updates -> The application should check for updates -> Before the application starts). Can this be achieved so that if more than one update is published before the user restarts the app, all updates are applied?

[lightlike]

There is no build in function for that. You can do that yourself on Application Startup before showing any Windows and then restarting the app. But keep in mind that the Squirrel restart method is currently bugged. I think you need to change the current directory for that one to work. (see #1562)