I have an Azure Automation PowerShell runbook that calls particular child runbooks based on input parameters. The child runbooks perform actions with different PowerShell modules. I believe Azure Automation is automatically loading/importing the required modules at the moment the child runbook is called. I would like to prevent this behaviour, and import modules manually using import-module.
In an Azure Automation account, is it possible to control if/when required modules are imported?
Edit:
Microsoft documentation outlining conditions where modules are imported.
This behavior, in Powershell, is controlled by one of the preference variables. More specifically, the $PSModuleAutoloadingPreference variable.
This variable control the automatic importing of module in the session.
By default, it is set to All, which automatically import modules on first-use.
Set this to None to disable the automatic importing of modules. You will need to explicitely use Import-Module for any command to be loaded.
Here's a snippet of the official documentation regarding preferences variiables and that variable specifically.
About Preference Variables
PowerShell includes a set of variables that enable you to customize
its behavior. These preference variables work like the options in
GUI-based systems.
The preference variables affect the PowerShell operating environment
and all commands run in the environment. In many cases, the cmdlets
have parameters that you can use to override the preference behavior
for a specific command.
...
$PSModuleAutoloadingPreference
Enables and disables automatic importing of modules in the session.
All is the default. To import a module, get or use any command in the
module. For example, use Get-Command. The
$PSModuleAutoloadingPreference variable does not exist by default. The
default behavior when the variable is not defined is the same as
$PSModuleAutoloadingPreference = 'All'.
Regardless of the variable's value, you can use Import-Module to
import a module.
The $PSModuleAutoloadingPreference variable takes one of the
PSModuleAutoLoadingPreference enumeration values: None,
ModuleQualified, or All.
Valid values are:
All: Modules are imported automatically on first-use.
ModuleQualified: Modules are imported automatically only when a user uses the module-qualified name of a command in the module. For
example, if the user types MyModule\MyCommand, PowerShell imports the
MyModule module.
None: Automatic importing of modules is disabled in the session. To import a module, use the Import-Module cmdlet.
Source: about_Preference_Variables
Related
I'm trying to create a powershell module to store some reusable utility functions. I created script module PsUtils.psm1 and script module manifest PsUtils.psd1 (used these docs). My problem is that when I import this module in another script Visual Code does not suggest parameters names. Here's a screenshot:
When I hover cursor over the function I only get this:
PsUtils.psm1
function Get-Filelist {
Param(
[Parameter(Mandatory=$true)]
[string[]]
$DirectoryPath
)
Write-Host "DIR PATH: $DirectoryPath"
}
PsUtils.psd1 (excerpt)
...
FunctionsToExport = '*'
I have Powershell extension installed. Do I need to install anything else to make the suggestions work? What am I missing?
Generally speaking, only auto-loading modules - i.e., those in one of the directories listed in environment variable $env:PSModulePath - are automatically discovered.
As of version v2022.7.2 of the PowerShell extension, the underlying PowerShell editor services make no attempt to infer from the current source-code file what modules in nonstandard directories are being imported via source code in that file, whether via Import-Module or using module
Doing so would be the prerequisite for discovering the commands exported by the modules being imported.
Doing so robustly sounds virtually impossible to do with the static analysis that the editor services are limited to performing, although it could work in simple cases; if I were to guess, such a feature request wouldn't be entertained, but you can always ask.
Workarounds:
Once you have imported a given module from a nonstandard location into the current session - either manually via the PIC (PowerShell Integrated Console) or by running your script (assuming the Import-Module call succeeds), the editor will provide IntelliSense for its exported commands from that point on, so your options are (use one of them):
Run your script in the debugger at least once before you start editing. You can place a breakpoint right after the Import-Module call and abort the run afterwards - the only prerequisite is that the file must be syntactically valid.
Run your Import-Module command manually in the PIC, replacing $PSScriptRoot with your script file's directory path.
Note: It is tempting to place the cursor on the Import-Module line in the script in order to use F8 to run just this statement, but, as of v2022.7.2, this won't work in your case, because $PSScriptRoot is only valid in the context of running an entire script.
GitHub issue #633 suggests adding special support for $PSScriptRoot; while the proposal has been green-lighted, no one has stepped up to implement it since.
(Temporarily) modify the $env:PSModulePath variable to include the path of your script file's directory.
The most convenient way to do that is via the $PROFILE file that is specific to the PowerShell extension, which you can open for editing with psedit $PROFILE from the PIC.
Note: Make sure that profile loading is enabled in the PowerShell extension's settings.
E.g., if your directory path is /path/to/my/module, add the following:
$env:PSModulePath+="$([IO.Path]::PathSeparator)/path/to/my/module"
The caveat is that all scripts / code that is run in the PIC will see this updated $env:PSModulePath value, so at least hypothetically other code could end up mistakenly importing your module instead of one expected to be in the standard locations.
Note that GitHub issue #880 is an (old) proposal to allow specifying $env:PSModulePath entries as part of the PowerShell extension settings instead.
On a somewhat related note:
Even when a module is auto-discovered / has been imported, IntelliSense only covers its exported commands, whereas while you're developing that module you'd also like to see its private commands. Overcoming this limitation is the subject of GitHub issue #104.
Does PowerShell supports private static variables in a PowerShell module (like a private static variable in C#)? If so, do I need a "special" syntax for it?
You should take a look at the about_Scopes documentation.
There is a script scope:
Script:
The scope that is created while a script file runs. Only
the commands in the script run in the script scope. To
the commands in a script, the script scope is the local
scope.
Also worth reading - Restricting Without Scope:
Modules:
You can use a Windows PowerShell module to share and deliver
Windows PowerShell tools. A module is a unit that can contain
cmdlets, scripts, functions, variables, aliases, and other useful
items. Unless explicitly defined, the items in a module are not
accessible outside the module. Therefore, you can add the module to
your session and use the public items without worrying that the
other items might override the cmdlets, scripts, functions, and other
items in your session.
The privacy of a module behaves like a scope, but adding a module
to a session does not change the scope. And, the module does not have
its own scope, although the scripts in the module, like all Windows
PowerShell scripts, do have their own scope.
I am using TFS2015 Release Management and Powershell DSC to manage the deployment of applications - previously I was using RM2013.
One thing I have noticed is that in RM2013, in my Powershell DSC scripts I was able to access variables such as $applicationPath - which was populated with the TFS Build Drop location, for use in the DSC scripts and MOF creation.
In RM2015 it doesn't appear that this works? I have tried using the variables listed here: https://msdn.microsoft.com/en-us/Library/vs/alm/Build/scripts/variables
However none of these ever seem to be populated?
Is there actually a way of using these RM2015 system & build variables from within a PS DSC script now?
Kind regards
Try to use the corresponding generated environment variables (for example $env:Build.DefinitionName).
If it not work try more ways such as $env:Build_DefinitionName or $(Build.BuildNumber) and $(Build_BuildNumber)
Just as the relevant documentation mentioned:
Any text input can reference a variable by using the $(variable_name)
syntax and will be substituted with the actual value at run-time. All
variables are also exported to the environment as upppercase and any .
are replaced with _. In scripts you can reference variables via the
environment, i.e. %VARIABLE_NAME%, $VARIABLE_NAME, $env:VARIABLE_NAME,
depeding on the operating system.
I have a powershell module I am writing and one thing I was curious of that is a bit unclear is the ScriptsToProcess Key. Can or should I use this to verify certain things like OS Type, Bit Type, or the presence or lack of certain environment variables to throw warnings if some of my functions may rely on some of the requirements above?
You can use ScriptsToProcess to execute script in the caller's session state (create variables, etc) or to use Write-Warning to notify the user the prereqs haven't been met. However, even if you throw an error, the module is still loaded. So if your intent is to prevent loading of the module I would put the warnings/throws in the startup script of your ModuleToProcess/RootModule. The module will show up in the Get-Module list but there shouldn't be any exported commands. Also if you want to check bitness, use the module manifest ProcessorArchitecture key.
I'm trying to set up a new build configuration in TeamCity using the Powershell runner. However, I can't seem to find a way to access the TeamCity System Properties in the build script. I've seen hints that it is possible, but cannot find documentation on how to do it.
I have tried accessing the system properties using Powershell variable syntax, $variable. I have also printed out all variables in memory and see no teamcity variables to use.
Is this possible with the Powershell runner, and if so what is the syntax necessary to get it working?
TeamCity will set up environment variables, such as build.number (you can see a list of these within TeamCity).
In Powershell you can access environment variables using the env "provider", e.g.
$env:PATH
TeamCity variables are accessible by replacing the . with a _, so the build.number variable can be accessed as
$env:build_number
As it says in the TeamCity documentation, the system parameters are passed to the build script runner, but not all build script runners know what to do with them. In the case of the Powershell script runner, when using a script file, they don't propagate down to your scripts.
It's occurred to me to write a psake-optimized build runner that does, but in the meantime you can do one of the following:
explicitly map any of the TeamCity build properties to script parameters using the parameter expansion that's available within the Script Source box. eg .\build.ps1 -someParam:%build.name%
use environment parameters, which can be accessed explicitly within PowerShell using $env:NAME_IN_TEAMCITY syntax, eg $env:TEAMCITY_VERSION, or looped over and pushed into variable scope
access the build properties file that TeamCity makes available during the build. The file is available at $env:TEAMCITY_BUILD_PROPERTIES_FILE, and if you load the XML version it's fairly easy to loop through and push them all into scope (though you do get everything as a string of course). I posted a gist on how to do this (https://gist.github.com/piers7/6432985). Or, if using Psake, modify the script above to return you a hashtable which you can pass directly to Psake's -properties argument.
It is posible. Here is example how to pass system properties into PSake script:
& .\psake.ps1 -parameters #{build_number=%build.number%; personal_build=%build.is.personal%}
If you don't use Psake, you can define your variables like this:
$build_number = %build.number%
The %build.number% part will be replaced with TeamCity provided data. I think, it works only in Source code script input mode.
I created a meta-runner that will pass through System parameters to parameters declared in the Powershell script. It's not perfect (if you put '# in your source it will break) but it works for what I needed, you can find it here: https://gist.github.com/anonymous/ef60ada3f48f0fb25093