Loading SMO in Your SQL Server-centric PowerShell Modules

In a recent version of PowerShell, Publish-Module, which publishes modules to the Gallery began requiring fully qualified Assembly names such as “Microsoft.SqlServer.Smo, Version=$smoversion, Culture=neutral, PublicKeyToken=89845dcd8080cc91”.

Previously, it was sufficient just to use short names such as Microsoft.SqlServer.Smo. This had similar behavior to LoadWithPartialName.

[System.Reflection.Assembly]::LoadWithPartialName(“Microsoft.SqlServer.Smo”)

Now, however, we must use the fully qualified name and this presents a problem for people who use SMO because we can’t be sure what version of SMO exists on the user’s system unless we’re specifically targeting an SMO version like Microsoft’s official module, SqlServer.

The Problem

When I tried publishing dbatools with just RequiredAssemblies = @(‘Microsoft.SqlServer.Smo’), I received the following error:

Publish-Module fails with “The specified RequiredAssemblies entry ‘Microsoft.SqlServer.Smo’ in the module manifest ‘…\dbatools.psd1’ is invalid. Try again after updating this entry with valid values.

I looked at the official SqlServer module to see how they handled RequiredAssemblies, and as mentioned previously, noticed that they addressed only the 2016 version of SQL Server SMO. I then looked through GitHub for how other people used RequiredAssemblies, both with and without SMO. Nobody else appeared to have a solution that addressed requiring one of an array of possiblities.

The Solution

I ended loading my assemblies in the psm1 file instead of using the ModuleManifest :3

What you can see in the code is that I iterate through all of the versions of SQL Server, including vNext, 2016, 2014 and so on, all the way down to 2005. If none are found, the module throws an informative exception. If SMO does load, the script then attempts to load the other associated assemblies.

Some assemblies such as Management.XEvent don’t exist in lower versions of SMO and will throw an error that I don’t care about – we handle version checks later on in our specific scripts such as Copy-SqlExtendedEvent.

Oh, and don’t worry about this loaded allll of those assemblies. It only takes 11-40 ms on my machine to run the above script.

So feel free to copy the code above to your own modules that use SMO or if you have a better way, let me know. Happy Holidays!

Chrissy is a PowerShell MVP who has worked in IT for nearly 20 years, and currently serves as a Sr. Database Engineer in Belgium. Always an avid scripter, she attended the Monad session at Microsoft’s Professional Developers Conference in Los Angeles back in 2005 and has worked and played with PowerShell ever since. Chrissy is currently pursuing an MS in Systems Engineering at Regis University and helps maintain RealCajunRecipes.com in her spare time. She holds a number of certifications, including those relating to SQL Server, SuSE Linux, SharePoint and network security. She recently became co-lead of the SQL PASS PowerShell Virtual Chapter. You can follow her on Twitter at @cl.

Posted in PowerShell, SQL Server
2 comments on “Loading SMO in Your SQL Server-centric PowerShell Modules
  1. Ben Miller says:

    Are you saying that you load EVERY smo version? That won’t be a good idea for those that use New-Object to get the objects in SQL. When you have multiple versions of SMO loaded and do a New-Object then it will use the lowest version which could be problematic if you have 10 on your machine and get a version 10 to manage a 13 version of SQL.

  2. Ben Miller says:

    Nevermind. I see what you did. You use the latest first in the list and New-Object actually uses the first one that is loaded. So if I load 14.0.0.0 first then I load 13.0.0.0 then the New-Object will use 14.0.0.0. If you load 13.0 first then it will use that even if you load 14.0 after. Thanks for letting me post.

Leave a Reply

Your email address will not be published. Required fields are marked *

*