Process Isolation | Post Install Script | Debug Shortcut

Process Isolation | Post Install Script | Debug Shortcut
 12-12-2018
4 Comments (4 New)
Duplicate

Sharing the ideas and feature requests put forth during the packaging workshop.

 

First idea relates to enabling of Process Isolation as an optional feature for enterprise for a limited period and phase out the same once MSIX adaptation grows widely.

 

  • Consider a scenario where in the organization would like to upgrade to version 2.0 of an application Sample_app for a new feature it introduced; However, a modification package Sample_mod of version 1.0 is not compatible with latest version of the application
  • It will be very helpful to have Process Isolation enabled for the version 2.0 of Sample_app for a limited period of time until there is an upgraded version 2.0 of the modification package Sample_mod is made available with all fixes
  • This would enable execution of two executables (Processes) with same name (but different version)

 

Second idea, which is also a request, is to introduce capability to run Post-Install script.

 

  • There could be scenarios such as – an application INI file contains Localhost address which is dynamically written at the time of application deployment
  • Understanding the purpose of MSIX, which is to eliminate the necessity to have custom actions, scenarios such as above turn out to be challenging without installation time actions
  • Having Post-Install script execution supported in MSIX will ease its adaptation for minority of applications as well which required such customizations

 

Last idea is more of a wish list item.

 

  • For the Packaging engineers, it will be a much helpful part if an optional Debug Shortcut (preferably a Command Prompt shortcut) option be provided (by default within the tool)
  • Engineers can use this option to debug and identify cause for issues using ProcMon, RegMon etc.
  • Once the Fix is developed, build the Final MSIX packaging with Fix by unselecting the Debug Shortcut option and release the Final build for end users

 

Will look forward for your response and support.

1 Upvote
Comment
Comments
Community Manager
Status changed to: New
 

@Nitty MDev 

 

Keep posting the ideas!  We need more people sharing theirs and discussing. Some feedback I would have on these...

 

#1 Perhaps I didn't understand the first item, but you can have two packages delivered in parallel to the same user with the same named exe in each package.  You simply have to have two differently named "applications" (i.e. "shortcuts") so the user can choose.  The name of the entrypoint application in the XML is different than the file name.

 

#2. This is exactly what we need, but it seems to fly in the face of what Microsoft wants to accomplish. One of the MSIX goals is to support a clean uninstall, so integrating something that might make changes outside of the environment is a no-no. So whatever the on-target-client customization consists of, it must be done within the container because who knows what your script will do. 

 

But currently, AppXInstaller doesn't support installing and then running such a script by starting it inside the container.  Maybe someday they can add it, who knows.

 

The best we can do today is to trigger activity upon launch, and have that activity leave a turd (yes, that is the technical term for it) behind to indicate it has been run, and that launch activity checks for the turd and skips the configuration when not needed.

 

If you are the developer of the app, you could include this logic in the startup code of the app itself.  When not, the Package Support Framework can help.  You could Add PsfLauncherXX.exe as the target of the app shortcut and configure the config.json file to first run your "script" as a monitor (waiting for it to complete) and then run the target app as the executable.  You have to be careful what this "script" is as we don't want to trigger any exes (like cmd.exe, wscript.exe, or powershell.exe) outside of the package.

 

A supported "install event script" capability would be much more straightforward than this, but this is what we have today.

 

#3. Unlike some other app runtime solutions, there is no need to run ProcMon inside the container.  But the idea of getting in with a command prompt or regedit to see the environment like the app sees it is important in debugging.  The problem, currently, is that any exe that is not inside the package doesn't run inside the container but pops out.  So a change to that limitation, either automatic or by request in some way, might be needed in order to get what we want.

 

 

 

Microsoft

broke out to separate items

Microsoft
Status changed to: Duplicate
 
Similar Ideas
No similar ideas