Is modular startup reliable?

Environment

I have the following folder structure where I store powershell modules:

C: PsModules ... util util.psm1 (this contains implementation of 'Test-Function') util.test.ps1 ftp ftp.psm1 http.test.ps1 ... 

c:\PsModules has about 50 folders and modules.

I set the PSModulePath environment PSModulePath to include c:\PsModules . This is similar to the conditions for “well-formed modules” described in the Microsoft documentation and this answer .

Symptoms

Sometimes Test-Function does not appear automatically when it is called from ISE. In fact, with any new start of ISE, there are always some (seemingly unpredictable) modules that are not found automatically. For example, Test-Function 's automatic search failure looks like this:

 PS C:\> Test-Function Test-Function : The term 'Test-Function' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. ... + FullyQualifiedErrorId : CommandNotFoundException 

At first glance, this seems to indicate that util.psm1 not "well formed." If it was not “correctly formed,” then ListAvailable should not work. But it works:

 c:\> get-module -ListAvailable util Directory: c:\PsModules\util ModuleType Version Name ExportedCommands ---------- ------- ---- ---------------- Script 0.0 util PS C:\> Test-Function ... + FullyQualifiedErrorId : CommandNotFoundException 

In addition, after calling Get-Command for a module, the commands in the module are available for general use:

 c:\> Get-Command -Module util CommandType Name ModuleName ----------- ---- ---------- Function Test-Function util c:\> Test-Function Call to Test-Function succeeded! 

Questions

  • Is automatic detection and automatic module loading reliable and predictable?

  • How to troubleshoot why powershell sometimes cannot find a command before calling Get-Command -module ?

  • Is it a bad practice to rely on powershell to automatically load modules? If so, what is good practice for automatically loading modules?

+7
source share
3 answers

I can’t say whether modular startup is reliable, but I personally don’t rely on it in the finished code.

If I write a script or module, I always use Import-Module TheModule -ErrorAction Stop and often use #Requires -Module AciveDirectory,TheModule,SQLPs to ensure the availability of modules.

For interactive use in the PowerShell or ISE console, I usually rely on automatic loading, but if that fails, I just Import-Module manually for the session.

In situations where I always want a specific module to load for an interactive session, I load it into the profile. To see how various profiles start this (from ISE and Console):

 $profile | Get-Member -MemberType NoteProperty 

You can decide where you want to put the code to import the module based on which user and on which host (s) you want the module to be available.

So far I am only doing this for posh-git , but it looks like it is well suited for your use.

+3
source

In case this is useful to someone else, I think this may be a problem exclusively for ISE. I could not reproduce, but recently went with MS about the inconsistent behavior of the ISE workflow, and after some efforts the problem was closed without a solution, with an official answer consisting in not using ISE, which is not approved for production, and instead use own shell. It was a realistic answer for us, I have never seen problems in our native shell. I wonder if this is so on this symptom?

+1
source

I found that the FunctionsToExport section in the module manifest cannot be set to *

THIS IS BAD:

 # Functions to export from this module, for best performance, do not use # wildcards and do not delete the entry, use an empty array if there are no # functions to export. FunctionsToExport = '*' 

IT'S GOOD:

 # Functions to export from this module... FunctionsToExport = 'Test-Function, Test-Function2' 
+1
source

Source: https://habr.com/ru/post/982856/