"Pre load" Powershell module

[HHarms]

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

[#2]

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/

[#3]

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 delay

[#4]

Hi
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 here

https://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..

[#5]

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

[#6]

Totally agree, even though it's still possible to add a prefix for a module.
https://www.sapien.com/blog/2016/02/15/use-prefixes-to-prevent-command-name-collision/
and it's also possible to prevent PowerShell from Autoload modules on startup, but this may have other impacts.
I was sooo confused when working with Exchange Online and Exchange On-prem the commands are similar and I needed both to be loaded as I was reading and comparing data from both.
I think it's better if the developer has a custom name for the module that reduces the possibility of having a conflict.

[#7]

Yeah it can be quite confusing, and with Exchange / Exchange Online having different commands wouldn't be ideal at all as they are more or less the same underlying code base (in very simplistic terms). In my scripts where I need to connect to both I will always call EXO with "cloud" prefix. have them both as a function that I can re-use for different scripts, and being able to connect to the Exchange on-prem tools from a standard PowerShell console, means people without specific Exchange knowledge are able to run the script(s) with only needing to provide the input data and know what the end outcome is :)