Can't switch SQLServer module versions in the same session

[Pxtl]

If I execute

import-module SqlServer -requiredversion 21.1.18256
remove-module SqlServer
import-module SqlServer -requiredversion 22.1.1

I get

Update-TypeData : Error in TypeData "Microsoft.SqlServer.Management.Smo.Server": The member UpdateLevel is already present.
At C:\Program Files\WindowsPowerShell\Modules\SqlServer\22.1.1\SqlServer.psm1:17 char:1
+ Update-TypeData -PrependPath $typeFile
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [Update-TypeData], RuntimeException
    + FullyQualifiedErrorId : TypesXmlUpdateException,Microsoft.PowerShell.Commands.UpdateTypeDataCommand

and the same occurs if I reverse the order:

import-module SqlServer -requiredversion 22.1.1
remove-module SqlServer
import-module SqlServer -requiredversion 21.1.18256

yields

Update-TypeData : Error in TypeData "Microsoft.SqlServer.Management.Smo.Server": The member UpdateLevel is already present.
At C:\Program Files\WindowsPowerShell\Modules\SqlServer\21.1.18256\SqlServer.psm1:17 char:1
+ Update-TypeData -PrependPath $typeFile
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [Update-TypeData], RuntimeException
    + FullyQualifiedErrorId : TypesXmlUpdateException,Microsoft.PowerShell.Commands.UpdateTypeDataCommand

Since 22.1.1 and 21.1.18256 have different APIs because of the -TrustServerCertificate switch, I need to be able to switch back and forth between them for executing new vs old scripts. Is there something I'm missing?

[Matteo-T]

Hi @Pxtl - I would say that the module was never designed with that kind of "cleanliness" in mind. :)

Due to the way .NetFx works (with Dotnet there is some hope, I think... if/when I get to redo the module and embrach ALC), but for now I say... it's an unsupported scenario - at least until the module is going to be dotnet-only....

Have you considered spawning a new pwsh.exe instead of trying to change during the same session?

[Pxtl]

Have you considered spawning a new pwsh.exe instead of trying to change during the same session?

Yes, that is a workaround I've been using since filing this bug. The problem was that it created the need to change over my devops scripts (which are often passing variables around to each other and so spawning new powershell sessions would be tricky) in One Big Bite instead of being able to do it incrementally. Regardless, in my use-case this issue is mostly handled since I've prettymuch wrapped up my move to 22.1.1