SOLVED

Issues with PowerShell start and end scripts

%3CLINGO-SUB%20id%3D%22lingo-sub-2340676%22%20slang%3D%22en-US%22%3EIssues%20with%20PowerShell%20start%20and%20end%20scripts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2340676%22%20slang%3D%22en-US%22%3E%3CP%3EI%20think%20there%20is%20a%20problem%20with%20the%20PSFLauncher.exe.%20It%20appears%20to%20be%20using%20the%20working%20directory%20of%20the%20application%20shortcut%20to%20find%20the%20StartingScriptWrapper.ps1.%20This%20is%20breaking%20PowerShell%20support%20in%20PSFTooling%20and%20Advanced%20Installer%20Express.%20Is%20this%20expected%20behavior%3F%20I%20can%20think%20of%20lots%20of%20reasons%20not%20to%20have%20things%20working%20this%20way.%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2348986%22%20slang%3D%22en-US%22%3ERe%3A%20Issues%20with%20PowerShell%20start%20and%20end%20scripts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2348986%22%20slang%3D%22en-US%22%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F1048312%22%20target%3D%22_blank%22%3E%40Skinheed%3C%2FA%3E%3CBR%20%2F%3E%3CBR%20%2F%3EThank%20you%20for%20posting%20in%20our%20forums.%20Thank%20you%20for%20bringing%20up%20this%20issue%20with%20PSF.%20The%20expected%20behavior%20for%20Powershell%20scripts%20is%20the%20root%20of%20the%20application%20directory%2C%20not%20the%20directory%20of%20the%20shortcut.%20This%20is%20an%20issue%20with%20PSF%20and%20would%20need%20to%20be%20fixed.%3CBR%20%2F%3E%20%3CBR%20%2F%3ECan%20you%20please%20make%20an%20issue%20on%20the%20MSIX_PackageSupportFramework%20github%20repo%20here%3A%20%3CA%20href%3D%22https%3A%2F%2Fgithub.com%2Fmicrosoft%2FMSIX-PackageSupportFramework%2Fissues%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%22%3Ehttps%3A%2F%2Fgithub.com%2Fmicrosoft%2FMSIX-PackageSupportFramework%2Fissues%3C%2FA%3E.%20This%20is%20where%20all%20the%20issues%20for%20PSF%20are%20being%20tracked.%3CBR%20%2F%3E%20%3CBR%20%2F%3EThanks%2C%3CBR%20%2F%3E%20%3CBR%20%2F%3EDarren.%3CBR%20%2F%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2350713%22%20slang%3D%22en-US%22%3ERe%3A%20Issues%20with%20PowerShell%20start%20and%20end%20scripts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2350713%22%20slang%3D%22en-US%22%3E%3CP%3EHi%20%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F1048312%22%20target%3D%22_blank%22%3E%40Skinheed%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20am%20Bogdan%2C%20from%20the%20Advanced%20Installer%20team.%20Thanks%20for%20reporting%20this%20issue.%20Just%20wanted%20to%20let%20you%20know%20that%20until%20a%20fix%20is%20included%20by%20MSFT%20in%20the%20official%20PSF%20repo%20we%20will%20include%20a%20custom%20fix%20directly%20inside%20our%20next%20version.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSTRONG%3EUntil%20then%2C%20you%20have%20a%20workaround%20in%20Advanced%20Installer%3A%3C%2FSTRONG%3E%3CBR%20%2F%3E%3CBR%20%2F%3E%3C%2FP%3E%3CP%3E%3CBR%20%2F%3EAdvanced%20Installer%20allows%20you%20to%20update%20the%20working%20directory%20and%20application%20parameters%20(that%20you%20would%20usually%20specify%20in%20the%20%22Application%20Details%22%20view)%20directly%20from%20the%20PS1%20script.%3CBR%20%2F%3E%3CBR%20%2F%3EFor%20your%20scenario%2C%20please%20follow%20these%20steps.%3C%2FP%3E%3COL%3E%3CLI%3EGo%20to%20%22Application%20Details%20%26gt%3B%20Working%20directory%22%20and%20make%20sure%20this%20field%20(Working%20Directory)%20is%20empty.%3C%2FLI%3E%3CLI%3EUse%20a%20PS%20script%20that%20updates%20the%20Working%20directory%2C%20attached%20is%20a%20sample.%3C%2FLI%3E%3C%2FOL%3E%3CP%3EThis%20sample%20PS%20script%20(from%20the%20attached%20zip)%20updates%20the%20Working%20directory%20to%20the%20first%20argument%20it%20receives%20(its%20value%20should%20be%20relative%20to%20APPDIR).%3CBR%20%2F%3E%3CBR%20%2F%3E%3C%2FP%3E%3CP%3EIMPORTANT%2C%20when%20using%20the%20above%20script%3A%3C%2FP%3E%3COL%3E%3CLI%3Echange%20the%20script%20to%20include%20your%20own%20%3CSTRONG%3EApplicationID%3C%2FSTRONG%3E.%3C%2FLI%3E%3CLI%3Eset%20the%20desired%20working%20directory%20path%20(relative%20to%20APPDIR)%20in%20the%20'%3CSTRONG%3EscriptArguments%3C%2FSTRONG%3E'%20field.%3CBR%20%2F%3EThe%20Working%20Dir%20argument%20can%20also%20be%20changed%20directly%20from%20inside%20your%20PS1%20script%2C%20if%20you%20wish%20to%20hardcode%20it%20inside%20the%20script.%3C%2FLI%3E%3CLI%3Eset%20the%20'%3CSTRONG%3EwaitForScriptToFinish%3C%2FSTRONG%3E'%20field%20to%20'%3CSTRONG%3Etrue%3C%2FSTRONG%3E'%3CBR%20%2F%3E%3CBR%20%2F%3ELet%20me%20know%20if%20this%20helps.%3CBR%20%2F%3E%3CBR%20%2F%3E%3C%2FLI%3E%3C%2FOL%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2352763%22%20slang%3D%22en-US%22%3ERe%3A%20Issues%20with%20PowerShell%20start%20and%20end%20scripts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2352763%22%20slang%3D%22en-US%22%3EDarren%2C%3CBR%20%2F%3E%3CBR%20%2F%3EI%20have%20gotten%20the%20same%20issue%2Frequest%20from%20another%20customer.%20PsfTooling%20is%20unable%20to%20place%20the%20file%20at%20the%20root%20folder%20since%20it%20doesn't%20exist%20yet.%20A%20modification%20to%20the%20launching%20code%20will%20be%20needed%20to%20allow%20for%20this%20case.%20It's%20actually%20a%20lot%20like%20the%20config.json%20file%20location%20issue%20I%20previously%20fixed.%20TMEditX%20does%20add%20these%20to%20the%20root%20folder%20of%20the%20package%20so%20it%20doesn't%20have%20this%20problem%20with%20scripts.%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2364092%22%20slang%3D%22en-US%22%3ERe%3A%20Issues%20with%20PowerShell%20start%20and%20end%20scripts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2364092%22%20slang%3D%22en-US%22%3EHi%20Bogdan%2C%3CBR%20%2F%3E%3CBR%20%2F%3EI%20have%20had%20a%20chance%20to%20test%20this%20out%20and%20the%20PowerShell%20script%20is%20still%20not%20being%20executed.%20Running%20Procmon%20I%20see%20no%20PowerShell%20process%20at%20all%2C%20only%20the%20AIStub.exe%20which%20is%20finding%20my%20script%20file%20in%20the%20application%20root.%20I%20don't%20think%20the%20StartingScriptWrapper.ps1%20is%20running%20either%2C%20I%20cant%20find%20any%20reference%20to%20it%20in%20Procmon.%20The%20application%20starts%20with%20no%20error%20it%20just%20doesn't%20run%20the%20script%20and%20I%20see%20no%20PowerShell%20window%20even%20though%20I%20have%20set%20it%20to%20show.%3C%2FLINGO-BODY%3E
Occasional Contributor

I think there is a problem with the PSFLauncher.exe. It appears to be using the working directory of the application shortcut to find the StartingScriptWrapper.ps1. This is breaking PowerShell support in PSFTooling and Advanced Installer Express. Is this expected behavior? I can think of lots of reasons not to have things working this way. 

11 Replies
@Skinheed

Thank you for posting in our forums. Thank you for bringing up this issue with PSF. The expected behavior for Powershell scripts is the root of the application directory, not the directory of the shortcut. This is an issue with PSF and would need to be fixed.

Can you please make an issue on the MSIX_PackageSupportFramework github repo here: https://github.com/microsoft/MSIX-PackageSupportFramework/issues. This is where all the issues for PSF are being tracked.

Thanks,

Darren.
best response confirmed by Skinheed (Occasional Contributor)
Solution

Hi @Skinheed 

 

I am Bogdan, from the Advanced Installer team. Thanks for reporting this issue. Just wanted to let you know that until a fix is included by MSFT in the official PSF repo we will include a custom fix directly inside our next version.

 

Until then, you have a workaround in Advanced Installer:


Advanced Installer allows you to update the working directory and application parameters (that you would usually specify in the "Application Details" view) directly from the PS1 script.

For your scenario, please follow these steps.

  1. Go to "Application Details > Working directory" and make sure this field (Working Directory) is empty.
  2. Use a PS script that updates the Working directory, attached is a sample.

This sample PS script (from the attached zip) updates the Working directory to the first argument it receives (its value should be relative to APPDIR).

IMPORTANT, when using the above script:

  1. change the script to include your own ApplicationID.
  2. set the desired working directory path (relative to APPDIR) in the 'scriptArguments' field.
    The Working Dir argument can also be changed directly from inside your PS1 script, if you wish to hardcode it inside the script.
  3. set the 'waitForScriptToFinish' field to 'true'

    Let me know if this helps.

Darren,

I have gotten the same issue/request from another customer. PsfTooling is unable to place the file at the root folder since it doesn't exist yet. A modification to the launching code will be needed to allow for this case. It's actually a lot like the config.json file location issue I previously fixed. TMEditX does add these to the root folder of the package so it doesn't have this problem with scripts.
Hi Bogdan,

I have had a chance to test this out and the PowerShell script is still not being executed. Running Procmon I see no PowerShell process at all, only the AIStub.exe which is finding my script file in the application root. I don't think the StartingScriptWrapper.ps1 is running either, I cant find any reference to it in Procmon. The application starts with no error it just doesn't run the script and I see no PowerShell window even though I have set it to show.
I'm not 100% sure this isn't a config issue. Can you show the Json file? I would also recommend that you use SysInternals DebugView for debugging this type of issue. The PsfLauncher code that handles the scripts outputs the information you need to see about script launching to the debug console.
Hi Tim,

Here is config.json from the Advanced installer package. I did manage to get it working with the PSFTooling after changing the config.json to use a relative path.

{
"processes": [
{
"executable": ".*",
"fixups": [
{
"dll": "FileRedirectionFixup",
"config": {
"redirectedPaths": {
"packageRelative": [
{
"base": "program",
"patterns": [
"__pycache__"
]
},
{
"base": "program\\python-core-3.5.7\\lib",
"patterns": [
".*"
]
},
{
"base": "share\\extensions\\dict-en\\pythonpath",
"patterns": [
"__pycache__"
]
},
{
"base": "share\\uno_packages",
"patterns": [
".*"
]
}
]
}
}
},
{
"dll": "AiShims",
"config": {
"dllDirectory": [
""
]
}
},
{
"dll": "CreateProcShim",
"config": {
"redirectedPaths": {}
}
},
{
"dll": "TraceFixup",
"config": {}
}
]
}
],
"applications": [
{
"id": "LibreOffice",
"startScript": {
"scriptArguments": "-Start -AppIDs LibreOffice,LibreOffice1,LibreOfficeClalc,LibreOfficeDraw,LibreOfficeImpress,LibreOffice,LibreOfficeMath,LibreOfficeWriter -WDSubDir Program",
"showWindow": true,
"waitForScriptToFinish": true,
"scriptPath": "Roam.ps1",
"timeout": 3000
},
"endScript": {
"showWindow": true,
"waitForScriptToFinish": true,
"scriptPath": "Roam.ps1",
"timeout": 3000
}
},
{
"id": "LibreOfficeWriter",
"startScript": {
"scriptArguments": "-Start -AppIDs LibreOffice,LibreOffice1,LibreOfficeClalc,LibreOfficeDraw,LibreOfficeImpress,LibreOffice,LibreOfficeMath,LibreOfficeWriter -WDSubDir Program",
"showWindow": true,
"waitForScriptToFinish": true,
"scriptPath": "Roam.ps1",
"timeout": 3000
},
"endScript": {
"showWindow": true,
"waitForScriptToFinish": true,
"scriptPath": "Roam.ps1",
"timeout": 3000
}
},
{
"id": "LibreOfficeCalc",
"startScript": {
"scriptArguments": "-Start -AppIDs LibreOffice,LibreOffice1,LibreOfficeClalc,LibreOfficeDraw,LibreOfficeImpress,LibreOffice,LibreOfficeMath,LibreOfficeWriter -WDSubDir Program",
"showWindow": true,
"waitForScriptToFinish": true,
"scriptPath": "Roam.ps1",
"timeout": 3000
},
"endScript": {
"showWindow": true,
"waitForScriptToFinish": true,
"scriptPath": "Roam.ps1",
"timeout": 3000
}
},
{
"id": "LibreOfficeDraw",
"startScript": {
"scriptArguments": "-Start -AppIDs LibreOffice,LibreOffice1,LibreOfficeClalc,LibreOfficeDraw,LibreOfficeImpress,LibreOffice,LibreOfficeMath,LibreOfficeWriter -WDSubDir Program",
"showWindow": true,
"waitForScriptToFinish": true,
"scriptPath": "Roam.ps1",
"timeout": 3000
},
"endScript": {
"showWindow": true,
"waitForScriptToFinish": true,
"scriptPath": "Roam.ps1",
"timeout": 3000
}
},
{
"id": "LibreOfficeMath",
"startScript": {
"scriptArguments": "-Start -AppIDs LibreOffice,LibreOffice1,LibreOfficeClalc,LibreOfficeDraw,LibreOfficeImpress,LibreOffice,LibreOfficeMath,LibreOfficeWriter -WDSubDir Program",
"showWindow": true,
"waitForScriptToFinish": true,
"scriptPath": "Roam.ps1",
"timeout": 3000
},
"endScript": {
"showWindow": true,
"waitForScriptToFinish": true,
"scriptPath": "Roam.ps1",
"timeout": 3000
}
},
{
"id": "LibreOfficeImpress",
"startScript": {
"scriptArguments": "-Start -AppIDs LibreOffice,LibreOffice1,LibreOfficeClalc,LibreOfficeDraw,LibreOfficeImpress,LibreOffice,LibreOfficeMath,LibreOfficeWriter -WDSubDir Program",
"showWindow": true,
"waitForScriptToFinish": true,
"scriptPath": "Roam.ps1",
"timeout": 3000
},
"endScript": {
"showWindow": true,
"waitForScriptToFinish": true,
"scriptPath": "Roam.ps1",
"timeout": 3000
}
},
{
"id": "LibreOffice1",
"startScript": {
"scriptArguments": "-Start -AppIDs LibreOffice,LibreOffice1,LibreOfficeClalc,LibreOfficeDraw,LibreOfficeImpress,LibreOffice,LibreOfficeMath,LibreOfficeWriter -WDSubDir Program",
"showWindow": true,
"waitForScriptToFinish": true,
"scriptPath": "Roam.ps1",
"timeout": 3000
},
"endScript": {
"showWindow": true,
"waitForScriptToFinish": true,
"scriptPath": "Roam.ps1",
"timeout": 3000
}
}
]
}

Thanks for the DebugView tip I will try that out now.
Hi Tim,

I get the following in DebugView:

[4132] StartingScript commandString=Powershell.exe -file StartingScriptWrapper.ps1 "Powershell.exe -file '.\Roam.ps1' -Start -AppIDs LibreOffice,LibreOffice1,LibreOfficeClalc,LibreOfficeDraw,LibreOfficeImpress,LibreOffice,LibreOfficeMath,LibreOfficeWriter -WDSubDir Program"
[4132] StartingScript currentDirectory=C:\Program Files\WindowsApps\LibreOffice.org.LibreOffice_6.2.8.0_x64__6pj9mnfdq70vt
[4132] StartingScript waitForScriptToFinish=true

It looks correct but still no PowerShell process appearing in Procmon while capturing the debug output. I would use my PSFTooling package that I have fixed but I can't get the MSPT to accept the package manifest after adding the fonts captured by PSFTooling.
PsfTooling provides you text to copy into the manifest, but must do so before the manifest exists so we had to guess how much to provide. It provides the minimal syntax that works for many packages, but depending on what else is in the package there may need to be more editing of the manifest to make the schema happy. For example, your package application may or may not have an <Application><Extensions> element to place the uap4:Extension into. But most of the time people have trouble because the app didn't reference the schema needed (UAP4) at the top of the file.

But even with what you have in AdvancedInstaller, if you just add a extra copy of the StartingScriptWrapper.ps1 into the working directory for the application you'll be fine. This is, essentially what PsfTooling is doing.

Hi @Skinheed,

 

I've published an update for AI Express in the store today (it should pass MS validation in a few hours). 

 

Download this update and try the old project. It should not require the workaround I suggested in my previous answer.

 

Cheers,

Bogdan

Hi Bogdan,

Thanks for the update. I did manage to get an RC version from your support team and the issue is fixed.

Thanks for your help

Craig
FYI (In case anyone runs into this issue) A fix for the issue is now up in my fork of the PSF. I'll be scheduling a pull request into the Microsoft develop branch soon.