/appvve equivalent

Copper Contributor



Will there be an equivalent for App-V's /appvve switch?





8 Replies

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.

Not at this time, but it is something we can look into longer term.

Thanks, John!


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?


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.



Hi Dian,


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.







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)


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 :)