Add clickonce migration guide

docs/migrating/clickonce.mdx

@@ -0,0 +1,48 @@
+# From ClickOnce
+<AppliesTo win />
+Migrate `ClickOnce` to Velopack.
+
+:::warning
+This is a relatively untested guide written with community feedback. If you have run into any issues which can improve the docs [please submit a PR or issue](https://github.com/velopack/velopack.docs/issues/new).
+:::
+
+It is not a straight-forward migration, since clickonce apps are very different to Velopack. The high level process overview is something like:
+- Ship a ClickOnce update which downloads and runs your Velopack app.
+- When the Velopack app starts, uninstall your ClickOnce app.
+
+
+### Your First Velopack Release
+We will need to start by publishing your first Velopack release.
+1. If you are using any of the `ApplicationDeployment` API's to check for updates, you will need to remove them.
+0. Turn off ClickOnce updates in your project settings, then manually open the `.csproj` and remove all ClickOnce related properties.
+   :::tip
+   If you are still on the legacy msbuild/csproj format, you should consider migrating to the SDK style project using the [dotnet/upgrade-assistant](https:// github.com/dotnet/upgrade-assistant) (The [VS extension](https://marketplace.visualstudio.com/items?itemName=ms-dotnettools.upgradeassistant) is easy to  use). You can continue to use .Net Framework, and the legacy csproj format may work however is not officially supported by Velopack.
+   :::
+0. Follow the [Velopack C# QuickStart](../getting-started/csharp.mdx) guide and/or review the samples to add Velopack updates to your application.
+0. Your first install of Velopack should uninstall your ClickOnce app. Ideally we would just run the default uninstaller, but since it cant be used unattended/silent, we need to include the [Wunder.ClickOnceUninstaller](https://github.com/rongchunzhang/Wunder.ClickOnceUninstaller) code. It is not currently distributed on NuGet, so you may wish to download and include the code directly in your project.
+0. Once `ClickOnceUninstaller` is added to your project, we can add a Velopack hook which uninstalls your clickonce app. You should already have `VelopackApp` in your main method at this point, and you'll need to modify it so that we add the clickonce uninstall code on Velopack install:
+   ```cs
+   VelopackApp.Build()
+       .WithAfterInstallFastCallback((appVersion) =>
+       {
+           var uninstallInfo = UninstallInfo.Find("Application Name");
+           if (uninstallInfo == null)
+           {
+               var uninstaller = new Uninstaller();
+               uninstaller.Uninstall(uninstallInfo);
+           }
+       })
+       .Run();
+   ```
+   Make sure you test this code independently to verify that it can uninstall your clickonce app successfully before moving on.
+0. 🎉 Compile your app and build your first release with `vpk pack`. You should see `YourAppSetup.exe` and some other files. We're now ready to ship a ClickOnce update which downloads and runs the Velopack setup.
+
+### Your Last ClickOnce Update
+The code in your final ClickOnce update will just install `YourAppSetup.exe` that we created in the previous section and will be fairly straightforward.
+1. You will likely want to bundle `YourAppSetup.exe` into your application as an embedded resource.
+0. On startup (eg. `Main` method), you may wish to show a dialog/message to the user to let them know you are about to migrate/update the app. 
+0. Then, extract `YourAppSetup.exe` to a temporary location (eg. the user downloads folder) and run it. If you wish this to be invisible, you can add the `YourAppSetup.exe --silent` arg. Otherwise, if you omit this argument the user will be shown a progress dialog.
+0. As soon as you've run `YourAppSetup.exe` you should quit your application, either by `return 0;` from `Main()` or via `Environment.Exit(0)`. Once your Velopack has installed, it will delete this app.
+   :::tip
+   To reduce the size of your ClickOnce app, you may wish to delete any unused code/dependencies in this update. Since the only purpose of this update is to run the Velopack installer, any code/dependencies which does not serve this purpose is just extra time/delay for the user.
+   :::

docs/migrating/squirrel.mdx

@@ -11,7 +11,13 @@ Here are the general steps needed:
    dotnet tool install -g vpk
    ```
 
-0. You will need to replace `SquirrelAwareApp` at the beginning of your app to `VelopackApp.Build().Run()`. Shortcuts [[Read more]](integrating/shortcuts.mdx) and registry entries are managed automatically for you in Velopack, so if you are currently doing this in `SquirrelAwareApp` hooks they should be removed. For example, if your hooks were this before:
+   :::tip
+   Make sure you are using the same version of vpk and the Velopack package, this is the only officially supported configuration.
+   :::
+
+0. You will need to replace `SquirrelAwareApp` at the beginning of your app to `VelopackApp.Build().Run()`.
+
+   Shortcuts [[Read more]](integrating/shortcuts.mdx) and registry entries are managed automatically for you in Velopack, so if you are currently doing this in `SquirrelAwareApp` hooks they should be removed. For example, if your hooks were this before:
    ```cs
    public static void Main(string[] args)
    {
@@ -50,9 +56,9 @@ Here are the general steps needed:
 
 0. The concept of `SquirrelAwareApp` no longer exists, so if you've added any attributes, assembly manifest entries, or other files to indicate that your binary is now aware, you can remove that. Every Velopack package has exactly one "VelopackApp" binary, which must implement the above interface at the top of `Main`. By default, Velopack will search for a binary in `{packDir}\{packId}.exe`. If your main VelopackApp exe is named differently, you should provide the name with the `--mainExe yourApp.exe` argument.
 
-0. The "RELEASES" file is no longer a format that Velopack uses, but it will produce one when building packages on windows with the default channel (eg. no channel argument provided). Instead, Velopack will produce `releases.{channel}.json` files, which should be treated in the same way. If you are wishing for a legacy windows app to migrate to Velopack, you should upload both the `RELEASES` file and the `releases.win.json` file which is produced by Velopack to your update feed.
+0. The "RELEASES" file is no longer a format that Velopack uses, but it will produce one when building packages on windows with the default channel (eg. no channel argument provided). Instead, Velopack will produce `releases.{channel}.json` files, which should be treated in the same way. If you are wishing for a legacy windows app to migrate to Velopack, you should publish a release (omitting the `--channel` arg) and upload both the `RELEASES` file and the `releases.win.json` file which is produced by Velopack to your update feed.
 
-0. In general, the command line supports all of the same features, but argument names or commands may have changed. Velopack no longer supports taking a `.nupkg` which was created by dotnet or nuget.exe. You should publish your app, and use `vpk pack` instead. A very simple example might look like this
+0. In general, the command line supports all of the same features, but argument names or commands may have changed. Velopack no longer supports taking a `.nupkg` which was created by dotnet or nuget.exe. You should compile/publish your app, and provide your compiler output to `vpk pack` instead. A very simple example might look like this
    ```cmd
    dotnet publish --self-contined -r win-x64 -o publish
    vpk pack -u YourAppId -v 1.0.0 -p publish -e yourMainBinary.exe
@@ -62,3 +68,4 @@ Here are the general steps needed:
    ```cmd
    vpk -h
    ```
+0. In your installed app, there are no longer `app-1.0.0` folders, and in a freshly installed app there will not be a `YourApp.exe` in the root of the application. Changing the path of the application (eg. app-1.0.0 and app-1.0.1) like Squirrel does is very bad, it breaks a lot of things in Windows. Firewall rules, antivirus issues, GPU preferences, tray icon pinning, and more. Maintaining the exe location in the same position after each update fixes many issues so velopack will always store your program at `{root}\current\YourApp.exe`. The first time your Squirrel app downloads a Velopack update, the Velopack updater will perform an app migration, it will look for shortcuts in all the usual/default locations and clean them up / repair them to point to the new location. If you previously had file associations or shortcuts outside of default locations pointing to `{root}\YourApp.exe` these will need to be updated since that file will no longer exist in new installs.

docs/troubleshooting/debugging.mdx

@@ -2,10 +2,9 @@
 <AppliesTo all />
 Find or configure application logs to find runtime issues.
 
-## Logging
 All parts of Velopack have logging built in to help troubleshoot issues, and you should provide these logs when opening a GitHub issue about a potential bug.
 
-### UpdateManager / In your application
+## Logging UpdateManager
 You should provide an instance of `Microsoft.Extensions.Logging.ILogger` to `VelopackApp.Run(ILogger)` and to `UpdateManager` to record potential issues. If you are not using Microsoft Hosting or Logging already, it is very simple to implement this interface yourself and log to a file, or integrate with another logging framework. 
 
 For example:
@@ -27,6 +26,8 @@ class ConsoleLogger : ILogger
 new UpdateManager("https://path.to/your-updates", logger: new ConsoleLogger());
 ```
 
+## Logging in the Velopack binaries
+
 ### Windows
 Running Update.exe will log most output to it's base directory as `Velopack.log`. Setup.exe will not log to file by default. However, you can override the log location for both binaries with the `--log {path}` parameter. You can also use the `--verbose` flag to capture debug/trace output to log. Unfortunately, on Windows, to avoid showing up as a console window, these binaries are compiled as a WinExe and there will be no console output by default.  Please see the [command line reference](cli.mdx) for a comprehensive list of arguments supported.