GeezerVison

Is it possible to have a simpler test case with a less complex file (either instead or additionally)?

Thinking of the problem on a higher level: We've only discovered that Packagemanagement cmdlet can cause this behaviour. What if more get discovered? It would be good to also have a global setting to disable the runspace pool caching. Is this issue a blocker for a release of a newer version of the vs code ps extension (which would implicitly start to ship with PSSA 1.18.1)? Do we want to have a 1.18.2 release (I would not mind as some useful commits like e.g. actionable error messages for settings files and various formatter fixes/enhancements have gone in already).

Please have a look at the build, there is a compilation error when compiling against net452

Please have a look at the build, there is a compilation error when compiling against net452

Bugger, can't use Array.Empty<T>() after all

Is this issue a blocker for a release of a newer version of the vs code ps extension (which would implicitly start to ship with PSSA 1.18.1)?

Yes it is. Ideally I'd like to address this issue and area more fully, but for now just trying to unblock.

Is it possible to have a simpler test case with a less complex file (either instead or additionally)?

So far this is the only good repro I've found in PSSA. Even then it's not 100%, but better than nothing.

What if more get discovered?

We've seen this in PSES as well and known about it for some time. It's because PkgMgmt does some extremely unusual threaded things to generate its dynamic parameters. Given that we haven't found any other cases and that this is caused by such a strange implementation, my feeling is thst the right approach is:

• Hotfix for PackageManagement in PSSA (this can remain in, since old versions of PackageManagement will be out there in use)
• Fix the issue in PackageManagement (which is more involved, and can't be relied upon to get to everyone)
• See if the mechanism allowing this to happen can be fixed in PS 7
• Possibly add more configurability to PSSA

In the meantime the PSES build could pin 1.18.0 in the call to Save-Module if you want to be able to quicker release an update to the extension before PSSA re-releases?

If not re-using a runspacepool does not cause the problem (if I've read the issue correctly), would it not be simpler to just have an option on GetCommandInfoLegacy to not re-use the runspace pool for the queried command only when the command is one of the Packagemanagement ones?

I thought about that, but:

• I feel like using the runspace pool is a legitimate thing to do
• We want the performance benefit of using it and doing it this way only makes things faster
• I feel it's uglier to poke a hole in the command info API than to work around the problem at the call site
• The deadlock itself is complicated enough that I'm not totally convinced that avoiding the runspace pool will totally fix the problem, unlike avoiding the problem path for the PackageManagement cmdlets

Christoph Bergmeister (@bergmeister) - I see the signoff for this but I just want to be sure before I merge it.