---
title: Using Custom PowerShell Modules
slug: using-custom-powershell-modules
createdAt: 2025-07-28T20:27:05.042Z
---

#

Activate V8 is based on .NET Core and uses PowerShell 7 to implement PowerShell integration.

PowerShell 7 modules are also written in .NET Core and can attempt to load some of the same DLL's as Activate. This is particularly common with Microsoft Modules and common DLL's like obtaining Azure Access tokens.

The issue becomes if the Module requires a higher module that is currently used in Activate. By default, in .NET Core higher versions of a DLL are assumed to be compatible and load will succeed.

This issue will be apparent when attempting to use a function where a specific 'DLL" fails to load.

The following link discusses the issue in more detail.

https\://learn.microsoft.com/en-nz/powershell/scripting/dev-cross-plat/resolving-dependency-conflicts?view=powershell-7.2#assembly-resolving-handler-for-side-by-side-loading




# Solution

There are a few ways to work around this.



## Replace the PowerShell module with an alternative method

Most use of PowerShell in Activate is custom scripts to connect to Azure. Most of these functions can be performed with the Microsoft Graph REST API instead. This avoids the use of PowerShell is the most robust solutions.




## Use a version of the PowerShell module that is compatible with the version of the conflicting DLL that Activate uses

It is possible to install older versions of the conflicting PowerShell module that are compatible with the versions that Activate is using. Most customers do not need the latest versions of these DLL's for the most commonly used functions.




Determining the version required can be a bit of trial and error. The easiest way is to find the version of the conflicting version that Activate is using and then find the release date and load a version of the PowerShell module from just after that time.




For example, this command installs a specific version of the Microsoft PowerShell SharePoint module.

Install-Module -Name Microsoft.Online.SharePoint.PowerShell -RequiredVersion 16.0.21909.12000




## Use the dependency out of process

This is a solution to use when confronted with a module that won't work due to an existing dependency conflict.

Dependency conflicts occur because two versions of the same assembly are loaded into the same .NET process. A simple solution is to load them into different processes, as long as you can still use the functionality from both together.




In PowerShell, there are several ways to achieve this:




Invoke PowerShell as a subprocess




To run a PowerShell command out of the current process, start a new PowerShell process directly with the command call:




PowerShell




pwsh -c 'Invoke-ConflictingCommand'

The main limitation here is that restructuring the result can be trickier or more error prone than other options.




The PowerShell job system




The PowerShell job system also runs commands out of process, by sending commands to a new PowerShell process and returning the results:




PowerShell




Copy

$result = Start-Job \{ Invoke-ConflictingCommand } | Receive-Job -Wait

In this case, you just need to be sure that any variables and state are passed in correctly.




The job system can also be slightly cumbersome when running small commands.




PowerShell remoting




When it's available, PowerShell remoting can be a useful way to run commands out of process. With remoting, you can create a fresh PSSession in a new process, call its commands over PowerShell remoting, then use the results locally with the other modules containing the conflicting dependencies.




An example might look like this:




PowerShell




Copy

\# Create a local PowerShell session

\# where the module with conflicting assemblies will be loaded

$s = New-PSSession




\# Import the module with the conflicting dependency via remoting,

\# exposing the commands locally

Import-Module -PSSession $s -Name ConflictingModule




\# Run a command from the module with the conflicting dependencies

Invoke-ConflictingCommand

Implicit remoting to Windows PowerShell




Another option in PowerShell 7 is to use the -UseWindowsPowerShell flag on Import-Module. This imports the module through a local remoting session into Windows PowerShell:




PowerShell




Copy

Import-Module -Name ConflictingModule -UseWindowsPowerShell

Be aware that modules may not be compatible with or may work differently with Windows PowerShell.