Install-DbaParquet - Keep the assemblies of the two PowerShell editions apart

[andreasjordan]

Import-DbaParquet failed every import on Windows PowerShell in the lab - 2 of 17 tests passing - while
the same file passed 17/17 on PowerShell 7. The warning said the assemblies could not be loaded:

Could not load file or assembly 'System.Collections, Version=10.0.0.0' ... |
Could not load file or assembly 'System.Runtime, Version=10.0.0.0' ...

The cause

Install-DbaParquet picks the assemblies that match the runtime it is running on: .NET Framework targets on
Windows PowerShell, net<major> targets on PowerShell 7. That part works. But it installed all of them into
one folder that both editions share, Path.DbatoolsParquet, default <AppData>\PowerShell\dbatools\parquet.

So whichever edition installs last decides what the other one finds. This installation had been made from
PowerShell 7, which left Parquet.dll and six of its dependencies as the net10.0 builds. Those reference
System.Runtime and System.Collections 10.0.0.0, which .NET Framework cannot bind, so Windows PowerShell
could not load them at all.

Nothing was wrong with the package versions, and Parquet.dll was exactly the pinned 5.4.0 - which is why
this reads like a broken or missing installation rather than a layout problem.

The fix

Each edition installs into its own folder below the configured path, desktop or core, chosen by the new
private function Get-DbaParquetEditionFolder. Get-DbaParquetPath looks in the folder of the running
edition first and falls back to the flat folder, so installations made before this change keep working.

Reporting an installation as already present now looks at the folder that would be written to rather than
at any folder Get-DbaParquetPath knows about. Without that, the other edition's assemblies counted as
installed and Install-DbaParquet skipped the install - so the command told you to run Install-DbaParquet,
and Install-DbaParquet then said it was already installed, with no way out except deleting the folder by
hand.

Import-DbaParquet also names the likely cause now when the assemblies are present but cannot be loaded, and
the help of Install-DbaParquet says which assemblies it installs and that both editions need their own run.

An explicit -Path is still used exactly as given.

Testing

In a lab with SQL Server 2019/2022/2025:

	before	after
Import-DbaParquet.Tests.ps1 on Windows PowerShell 5.1	2 passed / 15 failed	17 passed / 0 failed
Import-DbaParquet.Tests.ps1 on PowerShell 7.4	17 passed	17 passed (through the fallback)
Install-DbaParquet.Tests.ps1	2 passed	3 passed

The PowerShell 7 run deliberately used the pre-existing flat installation to confirm the fallback keeps old
installations working.

Install-DbaParquet.Tests.ps1 gains a test that installing without -Path lands in a subfolder named for the
running edition.

Note

Unrelated to this PR, but found next to it: Import-DbaParquet followed by New-DbaDacPackage in one
Windows PowerShell process crashes the process with an access violation. That survives this fix and is
tracked in #10536.

🤖 Generated with Claude Code

[potatoqualitee]

thank you 🙏🏼