Getting "Running scripts is disabled on this system." in ASP.NET Core Web API

Joel Coehoorn's helpful answer provides a key part of the puzzle:

• The implication is that the ASP.NET application runs with a different user identity than the one that shows Unrestricted as its current-user policy, and that that different user's current-user policy is either explicitly set to Restricted or - more likely - not defined (which Get-ExecutionPolicy -List reports as Undefined).

• In the latter case, the effective execution policy is defined by the LocalMachine scope; if the latter is Undefined too, the default is Restricted, preventing script-file execution - this is what you saw.

  • Note: If the execution policy is defined by GPOs (MachinePolicy or UserPolicy), it can not be overridden by other means.
  • For a comprehensive overview of PowerShell's execution policies, see this answer.

• In a PowerShell (Core) 7+ SDK project - unlike one for Windows PowerShell - a stand-alone PowerShell 7+ installation's LocalMachine policy is not visible to the SDK project, so the value of the LocalMachine policy when run from a stand-alone PowerShell 7+ session is irrelevant (as are Windows PowerShell's execution policies, which are entirely separate). However, the CurrentUser policy from a standalone PowerShell 7+ installation is seen and honored.^[1]

• The best solution is not to rely on a preconfigured execution policy to begin with, and instead use an SDK method to set the execution policy dynamically, for the current process only, as follows (this is the equivalent of using Set-ExecutionPolicy -Scope Process Bypass -Force):

  // Create an initial default session state.
  var iss = InitialSessionState.CreateDefault2();
  
  // Set its script-file execution policy (for the current session (process) only).
  // 'Bypass' uncondtionally allows script execution.
  iss.ExecutionPolicy = Microsoft.PowerShell.ExecutionPolicy.Bypass;
  
  // Create a PowerShell instance with a runspace based on the 
  // initial session state and run a sample script to show
  // that the process-level Bypass policy took effect.
  using (PowerShell ps = PowerShell.Create(iss))
  {
    Console.WriteLine(
      ps.AddScript(@"Get-ExecutionPolicy -List | Out-String").Invoke()[0]
    );
  }
  

^{[1] Windows PowerShell stores its (non-GPO) execution policies in a fixed location in the registry, whereas PowerShell 7+ uses powershell.config.json files. For the LocalMachine scope, this file is stored alongside the PowerShell executable, which for SDK projects is not the home directory of any stand-alone PowerShell 7+ installation (which may or may not be present, and can hypothetically be installed anywhere), but the directory of the SDK project's own executable, as reflected in the PSHOME environment variable. By contrast, the CurrentUser-scope powershell.config.json is seen and honored by SDK projects, because it is stored in an installation-independent, fixed directory relative to the user's home directory. Specifically, the CurrentUser policy is stored in "$([Environment]::GetFolderPath('MyDocuments'))/powershell/powershell.config.json", and the LocalMachine one in "$PSHOME\powershell.config.json" (with $PSHOME having different meanings in stand-alone PowerShell vs. SDK projects).
Note that this means that while you could hypothetically bundle a powershell.config.json file with your project with a preconfigured policy, it could still be preempted by a CurrentUser policy from a stand-alone installation. Only the dynamic, per-process policy override shown in the next bullet point can prevent that (except, as noted, if GPOs control the execution policy).}