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" o...
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..
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
Loading in the system profile other users may have no ideal and potentially do things with unexpected outcomes
- 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.- 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 🙂
