App update for Windows Store from Xamarin to MAUI (msixbundle) deleted user data

Question

App update for Windows Store from Xamarin to MAUI (msixbundle) deleted user data

Brian Conrad 111

I've had my Windows app in the Windows Store since 2017, updated the bundle numerous times but the new bundle which is the migration from Xamarin to MAUI unexpectedly deleted my user's data. The msix in the bundle for x64 was tested and it installed without deleting the user data so this was unexpected.

I used VS 2026 and the Windows Kit for it because the VS 2022 Windows Kit was no longer available. Previously one could just select what MSIX files could be included in the bundle via checkmark, run the process and the bundle was created. This time I had to complete the process manually by these steps:

https://learn.microsoft.com/en-us/windows/msix/packaging-tool/bundle-msix-packages#step-2-bundle-the-packages

Note these instructions are from 2022!

Is there something I missed in the Package.appxmanifest to prevent the deletion of user files. I never had to do that before and always the policy was the Microsoft would NEVER delete user data?

Also I am disappointed like other developers have mentioned that the process has become harder than easier.

0 comments

4 answers

Your answer

Answer 1

To finally fix this problem using along the lines of previously mentioned at startup I check if the expected database file is in the LocalState folder. If it is not there check the LocalCache/Local folder. If there then copy it from the LocalCache/Local folder to the LocalState folder. If it is not in the cache folder nor the state folder then it is a new install and no database yet created. What may have caused confusion is the way these folders were accessed in Xamarin Form vs MAUI. For clarity:

// MAUI LocalState folder
var dbpath = Path.Combine(FileSystem.AppDataDirectory, <database file>);

// cache file LocalCache/Local
string cachefile = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData), <database file>);

Answer 2

Brian Conrad 111

I am about to upload an update. It seems that Microsoft pushes having an ARM64 version but I don't have an ARM64 Windows machine since they are more expensive than a gold plated MacBook Pro. Highly unlikely any of my users would have such a PC plus if they do it can emulate the x64 version. I plan to a package flight first to see if it still deletes user data.

0 comments

Answer 3

Hi @Brian Conrad ,

Thanks for your feedback and for sharing the details from your migration experience.

I would still recommend continuing the migration path, especially since Xamarin is no longer the long-term direction for new development and maintenance. MAUI is the supported path going forward, but for a large existing desktop-style app, it is understandable that the migration can expose packaging, storage, and platform-specific UI issues that need to be handled carefully.

For the data issue specifically, I would also keep the startup migration/logging checks in place so the app can identify whether it is opening the expected MAUI data location, finding an older Xamarin location, or creating a new database.

If you run into separate MAUI migration issues, I would suggest opening new focused questions with the Developer technologies | .NET | .NET Multi-platform App UI tag so each issue can be investigated cleanly. We would be happy to help you.

If my explanation and the information I provided to you were helpful so far, I would greatly appreciate it if you could follow the instructions here so others with the same problem can benefit as well.

Answer 4

Jack Dang (WICLOUD CORPORATION) 18,975 Microsoft External Staff Moderator

Hi @Brian Conrad ,

Thanks for reaching out.

There is not a Package.appxmanifest setting that can be added to explicitly preserve user data. For MSIX-packaged apps, Windows keeps app data only when the new package is recognized as an update to the same package identity.

The first thing I would verify is whether the MAUI package is using exactly the same package identity as the previous Xamarin package. In particular, compare the Identity Name, Identity Publisher, Package Family Name, Store association, and make sure the version number is higher.

If the name or publisher changed during the migration, Windows will treat the MAUI package as a different app rather than an update. In that case, the previous package may be removed as part of the replacement process, and its data under %LOCALAPPDATA%\Packages\<old package family name> may be removed as well. There is no manifest flag that can force Windows to preserve data across different package identities.

I would also recommend inspecting the actual .msixbundle that was submitted to the Store and checking the manifest inside the architecture package, especially x64. Sometimes the standalone .msix tested locally has the expected identity, but the submitted bundle contains a package built with a different identity or publisher.

You can check that with makeappx unbundle and makeappx unpack, then compare the <Identity ... /> element with the one from the previous Xamarin package.

It is also worth checking whether the data was actually deleted, or whether the MAUI app is now reading from a different location. If the Package Family Name stayed the same, the existing data should normally still be under %LOCALAPPDATA%\Packages\<PackageFamilyName>\LocalState.

Going forward, the safest approach is to publish the MAUI app using the exact same Store package identity as the Xamarin app, then handle any internal data migration in the first MAUI release if the storage layout or APIs changed. If the package that was already published used a different identity and the previous package was removed, recovering that local data is usually not possible unless the app had backup, export, or cloud sync in place.

Hope this helps! If my explanation and the information I provided were helpful, I would greatly appreciate it if you could follow the instructions here so others with the same problem can benefit as well.

Brian Conrad 111 Reputation points

2026-05-21T22:32:16.26+00:00

Thanks for the reply. I did check the <Identity ... /> element and other than the version number the Xamarin and MAUI were identical.

I also looked at the Device family availability the app's packages and the version number was actually the date built which I found odd. But that shouldn't cause a problem because it is actually higher than the previous Xamarin number. This is a change from the usual listing as now it is <year>.<monthday>.<minute>.<0>.

For this release because of the dramatically content difference I labeled the file differently but again all the bundle files listed are slightly different so shouldn't be a problem.

The app is also storing the database under AppData/Local on my Win11 machine not under a package name and subdirectory. On a Win10 machine it stored it under AppData/Packages/<PackageFamilyName>\LocalCache not LocalState. BTW, some my users have noted that the location gets moved around from time to time. Why would that be?

I am wondering if this is more of a Store server problem than the bundle?
Jack Dang (WICLOUD CORPORATION) 18,975 Reputation points Microsoft External Staff Moderator

2026-05-22T09:00:20.8166667+00:00

Hi @Brian Conrad ,

Thanks for checking that and for sharing those additional details.

From my research, what you are seeing is more likely consistent with the app using a different data path after the Xamarin to MAUI migration than with a Store-side problem.

The reason the location can appear to move is that packaged desktop apps do not always resolve AppData the same way across Windows versions, app models, and storage APIs. So even with the same package identity, a Xamarin version and a MAUI version can end up reading or writing the database in different physical locations.

Because of that, I would treat this as less likely to be a Store server issue and more likely to be a storage-path difference introduced by the migration.

The suitable fix is to make the MAUI app use one stable app-managed location, such as ApplicationData.Current.LocalFolder or FileSystem.Current.AppDataDirectory, and add a one-time migration step. If the database is not in the new location, the app should check the older Xamarin paths, including any prior LocalCache or direct AppData\Local path, and then copy or move the database into the current MAUI location before opening it.

I would also log the exact runtime path used by the Xamarin build and the MAUI build so you can confirm whether this is a path-resolution issue rather than an actual deletion.

If my explanation and the information I provided so far were helpful to you, I would greatly appreciate it if you could follow the instructions here. Thank you.
Jack Dang (WICLOUD CORPORATION) 18,975 Reputation points Microsoft External Staff Moderator

2026-05-26T06:20:34.8166667+00:00

Hi @Brian Conrad,

I wonder if there is any update on this post. If you have any question, feel free to reach out. I'm happy to support you.
Brian Conrad 111 Reputation points

2026-05-26T22:31:03.1433333+00:00

Probably developers need to know that the user data location may change. But like I said a lot of documentation on this dates back to 2022. And I have sent feedback that it is the case. So some of my users learned their lesson the hard way even though I wrote articles about backing up as well as some instructional videos. Of course Android and iOS user data locations do not change.

One question though, how would one check older Xamarin paths before the app actually runs? By then it is too late as far as I can tell. Unless the Xamarin saved the path as a setting and the install doesn't wipe out the location.
Jack Dang (WICLOUD CORPORATION) 18,975 Reputation points Microsoft External Staff Moderator

2026-05-27T04:01:06.3066667+00:00

Hi @Brian Conrad,

Thanks for the follow-up. In this case, the suitable approach would likely be for the MAUI app to check a small list of known legacy paths used by the Xamarin version before it creates a new database.

As far as I am aware, there is no general Windows or Store API that will automatically tell the MAUI app where a previous Xamarin build stored arbitrary files, so the migration code would usually need to probe the known legacy locations explicitly.

For example, if you know the old database file name and package family name, the MAUI app could check candidate locations such as %LOCALAPPDATA%\Packages\<PackageFamilyName>\LocalCache, %LOCALAPPDATA%\Packages\<PackageFamilyName>\LocalState, and any direct %LOCALAPPDATA% path your Xamarin code used. If the database file is found in one of those locations, it could then be copied or moved into the current MAUI data folder before opening it.

If the old Xamarin app did not store the database in a predictable location, and did not save that location anywhere the MAUI app can still read, then there may not be a general platform API that can recover that information after the fact.

The limitation is that if the old location was already removed during the update flow, or if the old path cannot be reconstructed from the app's known storage pattern, then there may be nothing left for the MAUI app to recover.
Taki Ly (WICLOUD CORPORATION) 4,615 Reputation points Microsoft External Staff Moderator

2026-05-29T10:38:07.0666667+00:00

Hi @Brian Conrad ,

I’m Taki, Jack’s colleague. I just wanted to check whether you’ve had a chance to review Jack’s latest follow-up on this thread. Please note that Jack will be out of office for the next few days, so I’ll be assisting in the meantime. If you have any questions, feel free to reach out.
Brian Conrad 111 Reputation points

2026-06-01T02:07:06.5566667+00:00

What I'm adding to my app is a reminder if the users haven't backed up their database in over a week.
Jack Dang (WICLOUD CORPORATION) 18,975 Reputation points Microsoft External Staff Moderator

2026-06-01T04:20:43.0433333+00:00

Hi @Brian Conrad ,

Thanks for sharing the update.

I would also suggest making the backup location clear to the user, and if possible, offering an option to back up to a user-controlled location such as Documents, OneDrive, or another folder outside the app package data area. That way, the backup is not tied only to the app's install/update lifecycle.

This should help reduce the risk if the app data path changes again, or if the local app data is removed during an uninstall or unexpected migration issue.If my explanation and the information I provided were helpful so far to you, I would greatly appreciate it if you could follow the instructions here so others with the same problem can benefit as well. Thank you.
Brian Conrad 111 Reputation points

2026-06-03T01:19:05.2033333+00:00

In the Windows version the next update will list the current path of the database under Help. It also shows the date of the last database Export if there was one. Android and iOS are easier to deal with.

My app is actually a desktop app with 30,000 lines of code. My challenge was to build it in one solution rather that three as it's too easy overlook a change with multiple projects. Visual Studio is still not quite up to it. For instance it should be easier to switch between the iPhone and iPad profiles. Much of my app uses conditional tags to differentiate between the platforms. The idiom technique fall short because a three page or view main screen. In 2020 I began working on a upgrade version that would using two page responsive design. MAUI was announced back then and I think it was going to be ready by fall (uh-huh). Still not really there yet so it was painful to do the migration.
Brian Conrad 111 Reputation points

2026-06-04T23:06:17.9633333+00:00

I'll refer it to the recommend team as listed above. Thanks for what information you provided.
Jack Dang (WICLOUD CORPORATION) 18,975 Reputation points Microsoft External Staff Moderator

2026-06-05T02:18:52.4566667+00:00

Hi @Brian Conrad ,

Thanks for your feedback.

If the information I provided was truly useful to you, I would greatly appreciate it if you could follow the instructions here so others with the same problem can benefit as well. Thank you.
Jack Dang (WICLOUD CORPORATION) 18,975 Reputation points Microsoft External Staff Moderator

2026-06-08T09:50:28.7966667+00:00

Hi @Brian Conrad ,

Thank you for sharing your experience and feedback throughout this discussion.

At this stage, if you run into any new MAUI migration or storage-related issues, please feel free to open a new focused thread so they can be investigated separately.

Thank you again for the detailed discussion and feedback.
Brian Conrad 111 Reputation points

2026-06-28T21:44:42.1533333+00:00

I checked the identity on both the msixbundle for the Xamarin version and the one for MAUI. Except for the version number both is correct. The version number for the Xamarin version matches the one in the msix installation files in the bundle but on the one for the MAUI release it was year.monthday.time.0 makeappx default. But this of course is still higher than the actual version number and the time that date/time the bundle was created. This shouldn't seem to be the problem but maybe. Between the current uploaded version and a bundle I created for the next release it too also had the version as the bundle creation date. Testing this upcoming bundle it also erased the database file under LocalState when installed. I'll try the /bv switch with the actual app version to see if it helps.