MSIX Runtime: Support debugging using external launch

MSIX Runtime: Support debugging using external launch
 11-20-2018
12 Comments (12 New)
In the backlog

In order to easily debug packages, support for launching a non-package executable inside the package container is needed.  In App-V there are two methods to do this, either of which could be adopted:

  • A PowerShell cmdlet like Start-AppVVirtualProcess
  • A command line switch like /appvve

PowerShell would be the preferred method.  We could specify the package name to identify the container to run in.

 

This would allow us to debug in scenarios such as:

  • Launching a local PsfLauncherXX.exe with local config.json & tracefixup.dll to enable monitoring of a package without having to repackage.  Similarly to test a potential fixup fixup dll prior to repackaging.
  • Launching a tool like Regedit so as to see the registry the same as what the application would see.
0 Upvote
Comment
Comments
Microsoft
Status changed to: Duplicate
 
Community Manager
Status changed to: New
 
Microsoft
Status changed to: In the backlog
 

Hi @Tim Mangan

We have a PowerShell cmdlet that allows for running an executable inside the package container much like the Start-AppvVirtualProcess. 

 

It's the Invoke-CommandInDesktopPackage cmdlet. Give it a try and let us know if that's what you are looking for. 

 

Thanks,

Chaitanya

Frequent Contributor

Hi @Tim Mangan 

 

We will soon release a free tool to help with this. We have an older version of it built for a similar purpose with App-V packages, now we are expanding it for msix too.

AwesoneSause to both of you.

 

@Chaitanya Donthini I have to take back the awesomesause sent to you.  The cmdlet you mention requires running in developer mode.  Seems like run from a RunAsAdmin should be all that is required, if anything is required.

 

So double awesomesause to Bogdin, even if it doesn't translate well.

@Chaitanya Donthini I am thinking of IT Pro and Help Desk Scenarios where those parameters are not as easily known (yes, they can find out the AppID field but they don't generally want to deal with locating the XML. 

 

If someone does work to improve this cmdlet, in addition to removing restrictions, it seems like either PackageFamilyName OR AppID OR ProcessID of processes running in the environment should be sufficient to specify.    I was looking at one of the SDKs yesterday that seemed to want the ProcessId (or handle to it) to gather the package details of the others.  Sometimes, but not always, process name might be useful as ProcessID can be found from that (as long as only one copy is running). Cmdlets like Get-Process and Get-AppVVirtualProcess come to mind as examples.  Also the Package Name (the one without the hashed PublisherID) would be a better choice than PackageFamilyName. 

 

But if there were two copies of the app package running in different containers (a scenario we hope to see at some point) we'd need to be able to specify which one to inject the new process into, and ProcessID is a convenient way to specify it.  Certainly in an RDSH/RDMI situation today we'd need to target the package running in a certain user session anyway.

 

I'd also say that the online help for that cmdlet needs some love.  There are lots of placeholders like {{Fill in the Description}} everywhere in the help. PrevertBreakAway and Examples have placeholders and are not obvious..

Frequent Contributor

Hi @TIMOTHY MANGAN 

 

We've just released the first version of Hover, our free app that lets you easily launch an executable inside a MSIX container.

 

As I said earlier before, this tool is a wrapper over the PS cmdlet invoke-commandindesktop package. 

 

Don't hold back from sharing your feedback, it is more than welcome.

@Bogdan Mitrache 

 

So, maybe contribute it to the PSF?

 

Tim

Microsoft

I'd say add it to a toolkit repo we are about to launch.  Its less about PSF.

That's good too!

Similar Ideas
No similar ideas