SOLVED

MSIX AppAttach FSLogix Profile issue between packaged app versions

Occasional Contributor

Has anyone experienced the following scenario:

 

Application (PowerBI) packaged as MSIX and delivered via App Attach:

 

Package Name: PowerBI-2.104.702.0.MSIX

Delivered via App Attach to AVD

FSLogix Profile created, and Application user data stored path: \\CLIENTNAME.file.core.windows.net\fslogix\$GUID_username%\Profile_User_name.vhdx\ Profile\AppData\Local\Packages\PowerBI-2.104.702.0\LocalCache\Local\Microsoft\Power BI Desktop   (or similar)

 

End user can access application, app profile data is retained to FSLogix and works as expected between sessions, retaining app settings etc.

 

Now, a new version is required:

 

Package Name: PowerBI-2.104.941.0.MSIX

Delivered via App Attach to AVD

FSLogix Profile created, and Application user data stored path: \\CLIENTNAME.file.core.windows.net\fslogix\$GUID_username%\Profile_User_name.vhdx\ Profile\AppData\Local\Packages\PowerBI-2.104.941.0\LocalCache\Local\Microsoft\Power BI Desktop   (or similar)

 

 

So, between the different versions of the same Application, I am not able to access the roaming profile application data from the original package, forcing my users to have to re-configure the application afresh for the new release.

 

I could just repackage the new version using the EXACT SAME name, but this makes it impossible to differentiate between packages, and also does not meet any version control naming conventions.

 

Has anyone come across this before, and has anyone discovered a viable solution?

 

 

Thanks

 

Nick

 

2 Replies
best response confirmed by Nick-S (Occasional Contributor)
Solution

@Nick-S thank you for your question. The AppData root folder should be package family name based, so it works across different versions. Here it looks like FSLogix persisted app data in a version based folder. Looks like an FSLogix issue for me. One solution might be for you to change the app data folder name to exclude version number. 

Hi Aditi, Thanks for the reply, yes this turned out to be the cause of my issue:

Cause:
Used Package Full Name (PFuN) with version and not the Package Family Name (PFaN) without version

Resolution:
To upgrade the existing package , use Package Family Name (PFaN) without version; if the same Package Family Name (PFaN) IS Not used then this will result in a new package and the existing previous package settings will not migrate.

You should not put in the version alongside the Package Family Name (PFaN)

For application upgrades the Package Family Name must be consistent throughout.

The Version Control will come from the PFuN ( Package Full Name )