Updating Windows app losses data

[GoryMoon]

When I'm updating my app via Microsoft Store I've discovered that settings and other information is gone.
Looking into this I found out that the GetUserStoreForAssembly() function that is used uses the install location and assembly version to create a hash for the location.
This makes it so new updates on Windows creates a new folder and old data is lost.

I found this #357 that is similar, so the recommendation is just to use Legacy then? Even in 13.0.0?

[kgeminicdev]

Yes, WithLegacyFileLocation() is still how you get a stable location in 13.0.0.

With the default FileLocationOption.Default, the SQLite caches go under GetIsolatedCacheDirectory. On Windows that uses IsolatedStorageFile.GetUserStoreForAssembly() for UserAccount, Secure and SettingsCache, and GetMachineStoreForAssembly() for LocalMachine. As you found, those stores depend on the assembly, so an update can end up in a new folder.

With Legacy, the paths depend only on the application name:

• LocalMachine: %LOCALAPPDATA%\<AppName>\BlobCache
• UserAccount and settings: %APPDATA%\<AppName>\BlobCache
• Secure: %APPDATA%\<AppName>\SecretCache

Call it before WithSqliteDefaults(), because the directory is chosen when the caches are created:

AppBuilder.CreateSplatBuilder()
    .WithAkavacheCacheDatabase<SystemJsonSerializer>(builder =>
        builder.WithApplicationName("MyApp")
               .WithLegacyFileLocation()
               .WithSqliteProvider()
               .WithSqliteDefaults());

I don't see any code that moves existing data from isolated storage to the legacy paths. Users who already have data in the isolated store will start empty unless you copy the old .db files yourself. I haven't checked how MSIX redirects %APPDATA% for Store packages, so test an actual Store update with your package.