调用旧脚本时Setup.exe无法注册DLL的PowerShell问题

Alright, let's dig into this frustrating issue where your Setup.exe works perfectly on its own or via the old script, but fails to register DLLs when called from the new script. Here are actionable fixes to resolve this:

1. Ensure Elevated Privileges (Most Likely Culprit) #

Even if you're logged in as an admin, PowerShell scripts don't always run with elevated permissions by default. The old script might've been launched manually via an admin PowerShell window, while the new script is running in a non-elevated context.

Fix: Force Elevation with -Verb RunAs #

When calling the old script or running Setup.exe directly in the new script, use Start-Process with the -Verb RunAs parameter to enforce admin rights:

Option A: Call the old script with elevation

Start-Process powershell.exe -ArgumentList "-File `"$PSScriptRoot\oldScript.ps1`"" -Verb RunAs -Wait

Option B: Run Setup.exe directly in the new script

$setupPath = Join-Path $PSScriptRoot "Setup.exe"
$arguments = '/verysilent /LocationName="Test" (客户及许可证号等信息) /log="C:\temp\setup_log.txt"'
Start-Process $setupPath -ArgumentList $arguments -Wait -NoNewWindow -Verb RunAs

2. Fix Argument List Quoting Issues #

Your original old script uses ""Test"" for the location name, which works in the old context but might break under Set-StrictMode -Version 3.0 in the new script. PowerShell handles quote escaping differently in strict mode, so wrap the entire argument list in single quotes to avoid parsing errors.

Avoid this (prone to escaping issues):

-argumentlist "/verysilent /LocationName=""Test"" (客户及许可证号等信息) "

Use this (cleaner, no escaping needed):

-ArgumentList '/verysilent /LocationName="Test" (客户及许可证号等信息)'

3. Validate $PSScriptRoot in Strict Mode #

Set-StrictMode -Version 3.0 can make $PSScriptRoot behave unexpectedly if the new script is executed in a context where the variable isn't properly populated (e.g., running the script via the PowerShell ISE's "Run Script" without a saved file).

Replace $PSScriptRoot with a more reliable path resolver if needed:

$scriptPath = $MyInvocation.MyCommand.Path
$scriptDirectory = Split-Path $scriptPath -Parent
$setupPath = Join-Path $scriptDirectory "Setup.exe"

4. Check Setup.exe Logs for Exact Errors #

Silent installers often hide errors, so enable logging to get details about why DLL registration is failing. Add a /log parameter to your arguments to generate a log file:

$arguments = '/verysilent /LocationName="Test" (客户及许可证号等信息) /log="C:\temp\setup_detailed.log"'

Open the log file after a failed run—look for keywords like access denied (permission issue) or invalid parameter (argument parsing problem) to pinpoint the root cause.

Can You Run Setup.exe Directly in the New Script? #

Absolutely! In fact, cutting out the old script middleman can simplify troubleshooting. Just make sure you:

• Use -Verb RunAs for elevation
• Correctly format the argument list (single quotes around the whole string)
• Verify the path to Setup.exe is accurate (especially with strict mode enabled)

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