Webinar follow-up – #PowerShell Modules and Snap-Ins

This week my good chum Jason Himmelstein MVP (did I mention he was an MVP?) and I presented a 3 part training webinar for SharePointPro Magazine entitled “PowerShell for SharePoint Administrators”.

During the sessions, I said that I would endeavour to follow up with further materials so that the attendees could continue to get more out of their investment, and this post is the first follow up piece.

During the 2nd part of the event, Jason was talking to the subject of Modules and Snap-Ins and a question came in on the Q&A chat thingy asking about the material difference between Modules and Snap-Ins which we were unable to answer at the time as the session was running at light-speed with too many questions for us to answer.

SharePoint folks (since 2010) will be familiar with the SharePoint PowerShell Snap-In (Microsoft.SharePoint.PowerShell) and will probably use it on a daily basis, but are you actually au fait with what it is and how it differs from a module? Possibly not!

Snap-Ins are PowerShell extensions, usually containing a collection of technology or application specific cmdlets and providers compiled as a dynamic link library (.dll) that makes use of the .NET snap-in class that once loaded can be used within the context of the current PowerShell session.

Being .dll assemblies means that Snap-Ins are usually not that portable as they have to be registered with the operating system and often have many dependencies on other (in the case of SharePoint, numerous) assemblies in order to operate successfully. Often, the fact that dependencies on other assemblies exist is the determining factor in whether application specific cmdlets are created/loaded as modules or snap-ins.

Modules come in two types (if we ignore dynamic modules for today):

The first are simply existing PowerShell scripts that have been given a specific extension (.psm1) and are stored in the $PSModulePath (the environment variable denoting a location from which all modules are accessed) and are called “Script Modules”. Although best practice informs us that a certain diligence should be exercised when creating script modules in reality, the forgiving nature of PowerShell means that almost any scripts containing functions can be loaded as modules – whether this is good or bad is largely up for debate. The power of script modules is that they are quick to built-out (they’re just script after all) and they’re very portable as then can simply be copied from system to system and don’t require registration.

The second type of module, a “Binary Module” is conceptually very similar to a Snap-In in that it is compiled code providing cmdlets and providers by leveraging .NET classes with the exception that only .NET classes need be contained within the module, it is not necessary for a snap-in class to be part of the module. Less portable than script modules, binary modules have to be registered with the OS just like other dll files.

Whether you would choose to utilise a binary module as opposed to a snap-in is probably down to how you want to deploy and make use of the functionality. If you’re doing things for your own purposes and don’t have a ton of dependancies, it’s likely that a binary module would suffice, if you had more complex requirements, were considering distribution of your functionality (perhaps as part of something else) or had a bunch of dependencies (so you needed to make use of the CustomPSSnapin class available) then a snap-in might be the way to go.

Authors note: I’d welcome any input on the philosophy of choice you would use when choosing between binary module and snap-in