Sep 06 2020 06:48 AM
Sep 06 2020 06:48 AM
I have been giving some thought as to how an enterprise can have packages where the main application doesn't update very often, but IT needs to apply updates settings or data on a constant basis, possibly monthly, weekly, or daily. Quite often there is a back end service also involved in these updates, and the client piece must be kept in lockstep.
This proposal is an opining salvo; I have no intent to start on these proposed changes any time soon. But we need to start thinking about ways in which to better handle the enterprise need around this.
The proposal here is narrow - involving only the update of settings and data files, and not of updating the application executable bits.
One option available today would be to organize the main package so such files are referenced using VFS pathing within the package, and then create and distribute a modification package with the update and having the management automation remove the old modification package, if present. Versioning on the modification package might actually do that for us automatically, but that would need to be tested. The proposed goal is to eliminate the need to constantly package the changes.
This proposal would involve updates to the Package Support Framework PsfLauncher, and a new fixup shim (or integration into the existing FileRedirectionFixup).
The idea is to support the ability for the IT organization to update settings and data files using a technique very similar to what they often do today: utilize a server share, applying the updated files when needed to the files in this share. This could mean overwriting the existing server share files, or using directory naming under the share that forms a version numbering system allowing the new data files to be added to new folders. Such a share would be constructed as read-only for user accounts associated with the application.
There is a need to support two methods:
For both scenarios, it would be highly advantageous for the JSON file itself to be located in a VFS path rather than the root folder. In repackaging with the PSF and PsfTooling, we routinely work this way all the time and it works very well; software vendors creating their own package tend not to work this way, so additional instructions for them would be needed. The reason for this is that we would want the location of the server share to be indicated in the JSON file. If the JSON file is located in the main package in a VFS folder, then it is possible for the vendor to supply a valid JSON file with a placeholder for the server share and have the customer create a modification package (once) to replace the JSON file with their own.
There are plenty of options on how a solution to this problem could be implemented. I am not suggesting that this is the only, or the best, solution. I do, however, want to start the conversation now so that the community can provide input. The reply button is just a click away!