The app is SyncFolder (on the store) and the reasons of coming up with a win32 process for doing the actual copying/deleting of files and folders were:
- Full access to hidden folders/files in both the source and target location.
- Extended execution was (still is?) a no-go at that point in time to get the app in the Windows Store.
I am actually using AppServices when the win32 process is launched to communicate the task that is due to the win32 process. But since the background task scheduler that runs in the UWP app (using TimeTrigger) will be killed after half a minute (there is no UI active) the only way to communicate status information to the app when it is started at a given time by the user is by using LocalSettings.
An interesting feature by the way for these kind of problems would be to allow a win32 process in that case to be the listener for an AppServiceConnection instead of a client. But that is for probably good reasons not possible.
I am aware that with the latest Windows releases (XAML islands, etc..) starting from a win32 app and build from there the UI would have been a better approach.