Forum Discussion
"Pre load" Powershell module
My new Powershell module did have a load time of several seconds. Using this in a production environment is not an option with this long load time.
Is it possible to add this module to the "core" of powershell. So that it is already loaded before I start a new powershell session?
King regards,
Hans.Harms@centric.eu
- I guess this should help
You will need to play with PowerShell profile, so it will load a module each time you open PowerShell
https://msftplayground.com/2014/01/load-modules-by-default-when-openening-powershell/ - although adding the import-module into the PowerShell profile will load the module every time you open PowerShell it will add a several second delay to the PS console be usable, and depending on what profile you add the module to could effect every user that users that system (think RDS servers and the like) best case they might have a delay worse case they will get red errors due to access / permissions.
my biggest concern is what the module is actually doing - for example if we take Exchange and Exchange Online - the PowerShell modules are different - BUT the commands are the same - which could lead to major issues e.g. just deleting that brand new Exchange online mailbox rather than the on-prem one....
If the script is non interactive I personally wouldn't worry about the delay load up the module at run time - if the script is interactive provide the user some feedback (a percentage competed bar / write-host notification etc) to inform then of the delayHi
There is a Post I wrote about how to use a command from a module when there is a similar command in another module
check it from herehttps://www.powershellcenter.com/2020/12/01/get-vm-conflict-between-hyper-v-ps-and-powercli/
but in a summary, you will need to call the module name\the command.
Loading PowerShell module will sure take time, if you have something related to RDS and its must be loaded, then you need to make sure that the command are loading in async mode, not sync..- agreed that is a good way to handle them in a script. I was more pointing out the dangers of having a module always loading in PowerShell profile - as those commands are always available. things like prefix when connecting can assist minimising these dangers. if you're loading in your own PowerShell profile that's fine you wear the risk and know what's going on.
Loading in the system profile other users may have no ideal and potentially do things with unexpected outcomes
