In what scenario was Invoke-Expression designed to be used?

9/10 times if you are trying to use the Invoke-Expression cmdlet, there is a better way. Building the arguments to a command dynamically? Use an array of arguments. Building the arguments to a cmdlet? Use splatting with an array or hashtable. Your command has a space in the path to it? Use the call operator (&).

This might seem open ended, but Invoke-Expression is an easily accessible cmdlet where the answer is almost always to never use it. But the cmdlet exists for a reason, is not deprecated, and most criticisms of its use state something similar to, "it's almost never the right answer", but never states when it is acceptable to use it. In what case is it acceptable to use Invoke-Expression? Or to word it a bit less openly, how was Invoke-Expression designed to be used?

Update: An official deep-dive topic is now available: Avoid using Invoke-Expression

To quote from a PowerShell team blog post titled Invoke-Expression considered harmful (emphasis added):

The bottom line: Invoke-Expression is a powerful and useful command for some scenarios such as creating new scripts at runtime, but in general, if you find yourself using Invoke-Expression, you should ask yourself, or maybe a respected colleague if there is a better way.

EBGreen notes:

Or to phrase it another way, It [Invoke-Expression] is ok to use as long as a user is never involved in any part of generating the string that will be invoked. But even then, not using it will enforce better habits than using it would.

In short:

• As a matter of habit, always consider a different (usually more robust and secure) solution first.

• If you do find that Invoke-Expression is your only choice, carefully consider the security implications: if a string from an (untrusted) outside source (e.g., user input) is passed directly to Invoke-Expression, arbitrary commands may be executed.

  • Therefore: Only use Invoke-Expression if you fully control or implicitly trust the input.

Rare examples of justified (safe) use of Invoke-Expression:

• Effectively dot-sourcing PowerShell initialization code,

  • if provided via the output from a trusted executable.

• Creating PSv5+ custom classes dynamically:

  • so that the class can be used in a remote session.

  • so that the set of properties can be created based on conditions at runtime.

• Using Invoke-Expression in combination with Write-Output:

  • to parse a string with embedded quoting, with extra precautions.

  • to parse command lines stored in a file, if trusted.

• Using Invoke-Expression for nested property access:

  • via a property path stored in a string.

• Using namespace variable notation with a dynamically constructed name (though a simpler Set-Content alternative exists).