Import-DbaParquet - Stop leaving an assembly resolver registered for the whole process

[andreasjordan]

Fixes #10536.

Using Import-DbaParquet and then New-DbaDacPackage in the same Windows PowerShell session killed the
session - no error record, no exception, the process was simply gone with exit code -1073741819.

The cause

The AssemblyResolve handler that finds the Parquet.NET dependencies is a PowerShell scriptblock cast to
[System.ResolveEventHandler], and a scriptblock cannot run on a thread that has no runspace. It was
registered once per process and never removed, so anything that resolved an assembly on another thread later
on invoked it from a thread it cannot run on.

New-DbaDacPackage does exactly that - TSqlModel.Validate() runs on DacFx worker threads. There are two
outcomes depending on where the resolve lands:

• In a full suite run it surfaced as a caught error, Model validation failed: There is no Runspace available to run scripts in this thread (the real inner reason, unwrapped by New-DbaDacPackage - Report the real reason model validation failed #10527).
• Run directly after the Parquet tests it was worse, an access violation in the runtime itself:

Faulting application name: powershell.exe
Faulting module name: clr.dll, version: 4.8.9032.0
Exception code: 0xc0000005

New-DbaDacPackage is only the command that was noticed. Any multi-threaded .NET work that triggers assembly
resolution after an import was exposed.

The fix

The handler is only needed while the assemblies are being loaded, so it is registered right before the
Add-Type calls and removed again in a finally. The finally also covers the failure path, which returns
early.

Testing

Same process, same two test files, the only difference being whether the handler is still registered when the
second file runs:

handler after the Parquet tests	result of New-DbaDacPackage.Tests.ps1
still registered (before)	process dies, exit -1073741819
removed (after this change)	9 of 9 passed, process survives

The reason the handler was needed at all still holds - it is the load path that requires it, not the read path:

Import-DbaParquet.Tests.ps1 on Windows PowerShell 5.1	17 of 17
Import-DbaParquet.Tests.ps1 on PowerShell 7.4	17 of 17
Import-DbaParquet.Tests.ps1 then New-DbaDacPackage.Tests.ps1, one process	17 of 17, then 9 of 9

Note

This touches the same file as #10538 but a different part of it, and the two merge cleanly - verified by
merging them locally and running the tests above against the combination.

Note

Unrelated and pre-existing, seen while testing this: on PowerShell 7 the Parquet test file intermittently
fails Pester's TestDrive cleanup with The process cannot access the file 'staging.ecdc_parquet_test.parquet' because it is being used by another process. The 17 tests pass every time; it is the cleanup that fails,
roughly every other run, which looks like a file handle released only by the garbage collector. It predates
this change and is not addressed here.

🤖 Generated with Claude Code

[potatoqualitee]

thank you 🙏🏼