求助：C#调用PowerShell脚本在本地IIS部署后无法执行

Hey there! Let's figure out why your C# app can run PowerShell scripts fine in IIS Express but fails when deployed to local IIS—this is a super common issue, usually tied to permissions or execution policies. Here are the most likely fixes:

1. Fix the IIS App Pool Identity Permissions #

IIS Express runs under your user account (which has all the permissions you need), but local IIS uses a restricted service account by default (like ApplicationPoolIdentity or Network Service). These accounts don't have the rights to execute PowerShell scripts or access your script files.

• Open IIS Manager, navigate to your app's Application Pool.
• Right-click → Advanced Settings.
• Under Process Model, change the Identity to a user account with sufficient permissions (your local admin account works for testing, or create a dedicated service account for production).
• Make sure the account has read/execute access to your PowerShell script's directory and any resources the script uses.

2. Adjust PowerShell Execution Policies #

Your user account's execution policy might allow script runs, but the IIS app pool's account is bound to a stricter policy.

• Open Administrator PowerShell (64-bit) and run:

  Get-ExecutionPolicy -List
  

• Set a policy that allows local scripts (e.g., RemoteSigned is a safe middle ground):

  Set-ExecutionPolicy RemoteSigned -Scope LocalMachine -Force
  

• Important: If your IIS runs in 32-bit mode, repeat this in the 32-bit PowerShell (launch via C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe), since 32/64-bit environments have separate execution policies.

3. Grant File System Access to the App Pool Account #

Your script file and its parent folder might not let the IIS app pool account read or execute it.

• Right-click your script's folder → Properties → Security → Edit.
• Click Add, then enter the app pool identity (format: IIS AppPool\[Your App Pool Name]) and click Check Names to confirm.
• Grant the account Read & Execute and List Folder Contents permissions, then save changes.

4. Tweak Your C# PowerShell Code for Non-Interactive Environments #

IIS runs in a non-interactive session, which breaks some PowerShell features that rely on user profiles or desktop access. Adjust your code to handle this:

using System.Management.Automation;
using System.Management.Automation.Runspaces;

// ... your existing code ...

using (var ps = PowerShell.Create())
{
    // Disable user profile loading (avoids interactive dependencies)
    var runspaceConfig = RunspaceConfiguration.Create();
    runspaceConfig.ProfileFiles = ProfileFiles.None;
    
    using (var runspace = RunspaceFactory.CreateRunspace(runspaceConfig))
    {
        runspace.Open();
        ps.Runspace = runspace;

        // Set execution policy for the current process (avoids machine-wide changes)
        ps.AddCommand("Set-ExecutionPolicy")
          .AddArgument("RemoteSigned")
          .AddParameter("Scope", "Process")
          .AddParameter("Force")
          .Invoke();
        ps.Commands.Clear();

        // Run your script (use absolute paths to avoid working directory issues)
        ps.AddScript(@"C:\full\path\to\your\script.ps1");
        var results = ps.Invoke();

        // **Always log errors!** This is critical for debugging
        if (ps.HadErrors)
        {
            foreach (var error in ps.Streams.Error)
            {
                // Log to a file, event viewer, or your app's logging system
                System.Diagnostics.EventLog.WriteEntry("PowerShell Execution", error.ToString(), System.Diagnostics.EventLogEntryType.Error);
            }
        }
    }
}

5. Log Everything to Debug #

Never ignore error streams! The ps.Streams.Error collection will tell you exactly why the script failed—whether it's a permission denied error, a missing path, or an execution policy block. Log these details to a file or event viewer, and you'll save hours of guessing.

内容的提问来源于stack exchange，提问作者Abhishek