Fully qualify Read-SqlXEvent to SqlServer.XEvent\Read-SqlXEvent

[potatoqualitee]

We load an isolated DLL to get this command. Fully qualify it so there's no confusion with the SqlServer module.

Import-Module "C:\github\dbatools\bin\smo\SqlServer.XEvent.dll"
Get-command Read-SqlXEvent

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Cmdlet          Read-SqlXEvent                                     1.0.0.0    SqlServer.XEvent
Cmdlet          Read-SqlXEvent                                     21.1.18256 SqlServer

May help fix #8478

[RandyInMarin]

@potatoqualitee The Read-SqlXEvent cmdlet is also in Microsoft.SqlServer.Management.PSSnapins.dll in the coreclr set of dlls. If you added the non-coreclr version of this Microsoft.SqlServer.Management.PSSnapins.dll, could you remove the SqlServer.XEvent.dll?

Also, what would you think of making sure that all the dlls in the smo folder and it's subfolder all come from the same version of the sqlserver module? If you did so, we might be able to import both the dbatools module and a version of the SqlServer module at the same time without dll hell.

[potatoqualitee]

I didn't realize I'd left the PSSnapins DLL. I need to delete that.

I wanted all of them to be the same version but SqlServer lagged in keeping up with SMO. Automating the SMO process is on my todo list but I'm still waiting for alignment and features from Microsoft. I use various nugets including

• SMO
• DacFX
• SqlClient
• For both Full and Core

I usually delete non-essential DLLs to keep the package slim (Languages for sure then also some others that aren't in use after dbatools is imported) but maybe ill change that in the future.

Two problems I see for attempting to align with the SqlServer module is that their output formatting overrides ours and people say "I'm not seeing the same thing when I execute Get-DbaDatabase"

The other big problem is that SqlServer tends to lag with SMO and I don't want to make a promise that we use the same DLLs then not have the freedom to upgrade when a new version of SMO comes out. Plus, who knows if people will use a current version of SqlServer to match the dbatools version and the SMOs are out of alignment and we're back to the same problem.

I explored this idea as well but saw too many variables pointing to just warning people that we arent compat.