Using Custom PowerShell Modules

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