Jun 11 2018 01:41 AM
Jun 11 2018 01:45 AM
Thanks, I'm already very familiar with /appvve and RunVirtual :)
I'm trying to find out whether MSIX will provide similar support for launching native applications inside a VE.
Jun 11 2018 09:27 AM
If an MSIX-packaged Win32 application makes changes to the user profile (HKCU, %APPDATA%, %LOCALAPPDATA%, ...), will those changes always be isolated from the native profile? If so, is it possible to poke holes into that isolation at deployment time?
Jun 11 2018 03:00 PM
I'd like to understand your scenario a bit more. We currently have no plans to poke holes during the deployment. The changes made by the user or application can only be seen by applications in the same MSIX container.
Jun 12 2018 12:43 AM
I work at a large ISV on a product that allows roaming application settings across sessions and devices, independent of the Windows user profile.
For native Win32 applications, our agent can directly load and save these settings when the app starts and exits. For App-V apps, we use /appvve to launch our agent into the virtual environment, so that it can load and save the settings from inside of the bubble.
For MSIX I'd ideally see something like /msixve (:-), but if there would be another way for code running outside the VE to access the settings in the container, that might also work.
Happy to discuss this further if that's useful.
Jul 24 2018 01:24 AM - edited Dec 11 2018 11:52 PM
I don't have that much experience with App-V, so I might be missing something here.
Isn't the appve switch similar in functionality with the cmdlet Invoke-CommandInDesktopPackage?
P.S. We have an update in progress for this free tool, to also support msix/appx packages on top of its current support for app-v. It should help out a little bit more with debugging. (If you have any tips/improvements to recommend leave me a PM)
Jul 24 2018 03:27 AM
Thanks, Bogdan, you're not missing anything :) Invoke-CommandInDesktopPackage is pretty much the equivalent of Start-AppvVirtualProcess, so thank you for bringing that to my attention!
Unfortunately, behind the scenes the implementation has changed from a documented command-line argument to an undocumented COM interface, at least for now. Still, stuff to experiment with :)