Provide a way to "carry" content across releases

[christianrondeau]

I'm not sure about this one, but here goes.

My application has a configuration file (App.config), a log file and a Plugins directory where users can drop their extensions.

Because of the way Squirrel works (creating a different folder per version), those files are lost "in the midst of the past". My best option now is to have my app create another folder (e.g. in %AppData%) and put every file that can be modified there.

If you think this is the way to go, you can close this issue (and this can serve as a reference for people with similar wants), otherwise what do you think of being able to "carry" files over releases? Or maybe Squirrel could be "responsible" of setting up a data directory shared between version?

My intention is to setup a shared directory in %AppData%\MyApp when my app is run with --squirrel-install.

[anaisbetts]

Or maybe Squirrel could be "responsible" of setting up a data directory shared between version?

This isn't a terrible idea, just provide a simple property "DataDirectory" that we guarantee doesn't go away, which just returns a safe path (probably the root app dir + "data")

You should submit this as a PR :)

[christianrondeau]

Actually, after some thought, it is a terrible idea :) Here's my reasoning: There should be as little runtime dependency on Squirrel as possible.

Here are more reasons:

• If the application is installed using other means (e.g. zip), the application should still work (i.e. create it's data folder itself)
• If the user deletes the AppData\Roaming\MyApp directory, the runtime should be able to re-create it (equivalent of a "reset to factory settings")

So since I need to implement code for these two things, it won't be harder to support the first run setup as well. I'd close this issue, but since you maybe saw something else in it, I'll let you close it if you agree :)

[anaisbetts]

If the application is installed using other means (e.g. zip), the application should still work (i.e. create it's data folder itself)

Totally - so this property would probably have a very simple implementation that had no dependency on whether the app was correctly installed by Squirrel. Something like:

public class UpdateManager
{
    public string DataDirectory {
        get {
            var appDataDir = Path.Combine(ApplicationRootDirectory, "data");
            if (!Directory.Exists(appDataDir)) Directory.Create(appDataDir);
            return appDataDir;
        }
    }
}

Whether or not the app got dropped in via a zip, we don't care - we only effectively use the app name provided to UpdateManager.

If the user deletes the AppData\Roaming\MyApp directory, the runtime should be able to re-create it (equivalent of a "reset to factory settings")

Yep, it should be Squirrel's job to create this directory.

[christianrondeau]

I ended up simply re-creating the data directory at startup, everytime, using this code:

var dataFolder = Path.Combine(
    Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData),
    "MyAppName"
    );

if (!Directory.Exists(dataFolder))
    Directory.CreateDirectory(dataFolder);

Note that instead of AppData\Local, I used AppData\Roaming. This is because app configuration goes there (e.g. favorites, settings, user data). Squirrel is not aware of what kind of "data" is there...

So, maybe there should be two data folders; one under the application directory, as you said (next to the app versions) for cache data, per-install data and another for configuration (under roaming).

If such a feature is created, I would personally prefer it to be something like string SquirrelContext.CreateRoamingDirectory() and string SquirrelContext.CreateDataDirectory(), where SquirrelContext is an object that can be created and configured for the lifetime of the application (or a singleton), but separately from the UpdateManager. Their goal is different, and it might be good to have a way to get the path of the app, get the current version, create data directories and other non-update-related stuff like this.

[christianrondeau]

Actually, that might be three folders... data and logs folders under %LocalAppData%\YourApp, the roadming data under %AppData%\YourApp, and even a fourth if you also provide cache/temporary files under %temp%\YourApp. Those are all typical cases for which there is a standard approach, with the exception of logs, for which I think both Squirrel install logs AND application logs should be (I use ${LocalAppData}\MyApp\logs\MyApp.log in log4net). That would make sense and justify such a utility since you'll need these folders anyway for setup logs and install files.

[anaisbetts]

Their goal is different, and it might be good to have a way to get the path of the app, get the current version, create data directories and other non-update-related stuff like this.

I'm not super excited about this, if only because it's pretty easy to create UpdateManagers (i.e. all you need is your application name and an update URL). I'd rather have everything be in one place.

So, maybe there should be two data folders; one under the application directory, as you said (next to the app versions) for cache data, per-install data and another for configuration (under roaming).

I like this idea - not so sure about the logs bit, but the Remote vs Local is 👍