File Rediection Selectable Destination

MVP
In reference to the PSF Issue #5 in the feedback hub (https://github.com/Microsoft/MSIX-PackageSupportFramework/issues/5 ), is Microsoft willing to accept external contributions?  I believe that a project to expand the functionality for directed redirection is necessary, and would be willing to work on doing so.
 
Rational:
Applications create and consume all sorts of data.  Some of that data should follow the user and some should not. Older applications, many of which remain in use in large enterprises for decades, do not always place this data in the correct locations.  And IT Pros creating MSIX packages do not have access to source code so some sort of redirection is required.
 
App-V 4.x solved this problem by design, by redirecting all written package data to a location that would roam, without anyone having to think about it.
 
App-V 5.x automatically redirected data that the app wrote to non-roaming locations to a non-roaming location and roaming locations to a roaming one.  IT Pros could ignore data placement on most of these apps, but those that wrote important data that needed to be kept to non-roaming locations had to be individually dealt with.  We use a scripting tool to copy things around (start/end VE) or we use the old AppCompat toolkit to develop a shim that must be deployed.
 
The current PSF seems to require adding a shim to any app that writes data within its package boundaries. I like that the shim ends up part of the package and doesn’t need separate deployment, but it is extra work already. That ALL data is redirected to AppData/Local will not meet the needs of the enterprise.  Some of that data needs to be redirected to a roaming area (this might mean roaming profiles, folder redirection, Home drives, UEV, other  UEM products, or even Cloud Sync such as One Drive ), and the current implementation does not support control to do this.
 
If Microsoft is not interested in community collaboration on the PSF, we will have to push tool vendors (which might be me, but I hope not) to develop a better shim system.

Tim
1 Reply
Hey Tim. Yes we are willing to review external contributions. A main reason for the open source was to enable this level of collaboration. John.