locked
[UWP] [Desktop Bridge] Local App Data RRS feed

  • Question

  • Hi,

    I am converting a Win32 app to the AppX model using the "Desktop Bridge" converting tool.

    The Win32 installer tries to save all files that should be write-accessible to "CSIDL_LOCAL_APPDATA" (%localappdata%) by getting the folder's path by calling "SHGetFolderPath" with "CSIDL_LOCAL_APPDATA".

    The problem is that after the conversion, with the resulting AppX is installed, the write-accessible files are written to:
    C:\Program Files\WindowsApps\ZoomPlayer_12.5.0.0_x86__63ghcm0aqanjp\VFS\Users\ContainerAdministrator\AppData\Local\Zoom Player

    Which is NOT write accessible.

    If I then use SHGetFolderPath with "CSIDL_LOCAL_APPDATA" from within my actual App and  then try to write a file to the resulting folder, the file is saved to:
    c:\users\[username]\appdata\local\packages\zoomplayer_63ghcm0aqanjp\LocalCache\Local\Zoom Player

    What I want to understand is why the AppX installer writing the files targeted for modifications under the "C:\Program Files\WindowsApps\ZoomPlayer_12.5.0.0_x86__63ghcm0aqanjp\VFS\Users\ContainerAdministrator\AppData\Local\Zoom Player" path and not in the desired path of "c:\users\[username]\appdata\local\packages\zoomplayer_63ghcm0aqanjp\LocalCache\Local\Zoom Player" ?


    • Edited by Inmatrix Thursday, September 8, 2016 10:40 AM
    Thursday, September 8, 2016 10:38 AM

Answers

  • Is it impossible for the AppX installer to automatically place some files into the local app data folder?

    Yes. The recommended pattern is to include the template files in the install package and then copy them to the local app data folder on first use.

    When an app package is installed it's just copied into the system. It doesn't run any initialization code. It doesn't know which users will run the app and doesn't have access to their user data. If a second user installs the app then the user gets a reference to the already-installed app and nothing new is copied or installed.

    A normal Win32 installer doesn't only place files into the "Program Files" folder, it places editable files into the "Local AppData" folder

    When you run the Desktop App Converter it runs the install and captures the data into the app package at the time you run the converter. The user running the converter and that user's app data do not have any relation to the user or users who may install the app later.

    The call to SHGetFolderPath in the installer runs in the installer context when being converted, so it gets captured into the package the same as any other file written by the installer during conversion. SHGetFolderPath(CSIDL_LOCAL_APPDATA) gets mapped to the ApplicationData.LocalFolder only when the converted app is already installed and running.

    This is a problem scenario that probably should be called out in the Prepare your desktop app for conversion to UWP document. Thank you for pointing it out. I'll file a doc request on this.


    • Marked as answer by Inmatrix Tuesday, September 13, 2016 7:35 AM
    Monday, September 12, 2016 7:53 PM

All replies

  • Hi Inmatrix,

    There is an offical document about Prepare your desktop app for conversion to UWP, please refer that in this link: https://msdn.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-root#prepare-your-desktop-app-for-conversion-to-uwp.

    In the document it said that:

    Your app writes to the AppData folder with the intention of sharing data with another app. After conversion, AppData is redirected to the local app data store, which is a private store for each UWP app. Use a different means of inter-process data sharing. For more info, see Store and retrieve settings and other app data.
    Your app writes to the install directory for your app. For example, your app writes to a log file that you put in the same directory as your exe. This isn't supported, so you'll need to find another location, like the local app data store.

    Best Regards,

    Jayden Gu

    Friday, September 9, 2016 1:04 PM
  • Hi Jayden,

    The cases you highlighted do not apply to my situation, I am not trying to share data with external applications or save files to the installation path.

    My application includes several editable (only by my application) configuration files, for example as a media player, there is an "audio equalizer" profiles file.  My Win32 installer calls the WinAPI function SHGetFolderPath with the parameter CSIDL_LOCAL_APPDATA to determine the local appdata folder and then writes these configuration files.

    The problem is, after the conversion of the Win32 installer to an AppX package using the Desktop Bridge component, the installed AppX files destined for the local appdata folder are instead written to C:\Program Files\WindowsApps\ZoomPlayer_12.5.0.0_x86__63ghcm0aqanjp\VFS\Users\ContainerAdministrator\AppData\Local\Zoom Player" a read-only folder which is not accessible to my application's EXE (see below).

    When my application's EXE calls the WinAPI function SHGetFolderPath with the parameter CSIDL_LOCAL_APPDATA I determined the local appdata folder by writing a small text file.  The resulting text file was written to the real path of c:\users\[username]\appdata\local\packages\zoomplayer_63ghcm0aqanjp\LocalCache\Local\Zoom Player

    The fact that the files destined for local appdata are installed in a different path prevents my own application from accessing and modifying the files.

    P.S.

    I read the Prepare your desktop app for conversion to UWP document prior to writing on the forum.

    • Edited by Inmatrix Friday, September 9, 2016 8:18 PM
    Friday, September 9, 2016 8:13 PM
  • Since I did not get any reply, I had to fall-back to an ugly solution of first installing all the files into the program files directory and then manually copying the files that I need write-access to from within the actual app.

    If anyone can find an alternative solution so that the AppX installer copies the local appdata content to the correct folder, I would appreciate it.

    Monday, September 12, 2016 10:11 AM
  • Hi Inmatrix,

    The "C:\Program Files\WindowsApps\ZoomPlayer_12.5.0.0_x86__63ghcm0aqanjp\VFS\Users\ContainerAdministrator\AppData\Local\Zoom Player" location is is not write accessible. The app's install directory is a read-only location, it is probably by design.

    There is a document about File access permissions, please refer that in this link: https://msdn.microsoft.com/en-us/windows/uwp/files/file-access-permissions.

    It seems you want to save the several editable configuration files and writes these configuration files. As a workaround we can set the files into the install dir and then copies to the app data for when the app is first run.


    Best Regards,

    Jayden Gu

    Monday, September 12, 2016 11:49 AM
  • Hi Jaiden,

    Why is the AppX installer placing files specifically destined the local app data into a read-only folder?

    Is it impossible for the AppX installer to automatically place some files into the local app data folder?

    By this I mean: A normal Win32 installer doesn't only place files into the "Program Files" folder, it places editable files into the "Local AppData" folder, usually under "C:\Users\Inmatrix\AppData\Local\Zoom Player" which is determined in the installer by calling "SHGetFolderPath" with the "CSIDL_LOCAL_APPDATA".  This is a specific folder where Win32 apps should have write access.  However, after converting the installer using Desktop Bridge, the resulting AppX package does not install these editable files into the AppX's local storage folder as expected, instead it installs them in a read-only folder which is unreachable by the APP's EXE file.

    This seems very basic to me, a big number of Win32 apps install their editable files into the local app storage folder, why is virtualization broken here?

    Monday, September 12, 2016 7:04 PM
  • Is it impossible for the AppX installer to automatically place some files into the local app data folder?

    Yes. The recommended pattern is to include the template files in the install package and then copy them to the local app data folder on first use.

    When an app package is installed it's just copied into the system. It doesn't run any initialization code. It doesn't know which users will run the app and doesn't have access to their user data. If a second user installs the app then the user gets a reference to the already-installed app and nothing new is copied or installed.

    A normal Win32 installer doesn't only place files into the "Program Files" folder, it places editable files into the "Local AppData" folder

    When you run the Desktop App Converter it runs the install and captures the data into the app package at the time you run the converter. The user running the converter and that user's app data do not have any relation to the user or users who may install the app later.

    The call to SHGetFolderPath in the installer runs in the installer context when being converted, so it gets captured into the package the same as any other file written by the installer during conversion. SHGetFolderPath(CSIDL_LOCAL_APPDATA) gets mapped to the ApplicationData.LocalFolder only when the converted app is already installed and running.

    This is a problem scenario that probably should be called out in the Prepare your desktop app for conversion to UWP document. Thank you for pointing it out. I'll file a doc request on this.


    • Marked as answer by Inmatrix Tuesday, September 13, 2016 7:35 AM
    Monday, September 12, 2016 7:53 PM