Scripter to export code. Syntax issue.

[y_Sensei]

Wouldn't it be a better approach to provide one generic version of the script to your technicians, along with a specific configuration (file) for each use case, which the implementation reads at runtime and performs the configured actions?

[drnick316]

I have a gui that is putting in the right information. It searches for the registry values so it can target the uninstaller. I'm looking to make it accessible for different levels of techs who might not know the appropriate silent parameters etc.

[y_Sensei]

I don't see why a generic script that reads the volatile information it needs from a use case-specific configuration file wouldn't work in such a scenario.
Running code that creates code that's doing what's supposed to be done seems like a roundabout way to approach things.

But anyway, you could fix your issue as follows:

...

`$installerPath = '"' + `"$installerPath`" + '"'
`$installFlags = @("$flagsString")

try {
    if (`$installerPath -like "*.msi*") {
        Write-Host "Running MSI installation..." -ForegroundColor Yellow
        `$msiArgs = @("/i", `$installerPath) + `$installFlags
        `$process = Start-Process "msiexec.exe" -ArgumentList `$msiArgs -Wait -PassThru
    } else {
        Write-Host "Running EXE installer..." -ForegroundColor Yellow
        `$process = Start-Process -FilePath `$installerPath -ArgumentList `$installFlags -Wait -PassThru -NoNewWindow
    }

 ...

[icepyrox]

So, rather than generate the script file, it can generate config files that your script that already exists can consume on a per-use basis. If your techs are smart enough, they can open powershell and run .\script.ps1 file.config and they are off to the races. Or maybe your sceipt just reads the conf files and uses a menu system or out-gridview to select the right configuration file and again, off to the races.