When a processes under the influence of the PSF starts a new process, this action is caught by the version of PsfRuntime in the calling process (CreateProcessHook). This code will create the new process as suspended, and then (attempt to) inject a fresh copy of PsfRuntime into the new process.

The current code (around lines 164-173 of the develop branch) uses psf::runtime_dll_name which returns the name assuming the bitness of the calling process. So if a 32-bit process is starting a 64-bit process that injection will fail (or visa versa). The result is that the new process never gets a chance to run.

This code will need to be updated. Probably best is to look at the bitness of the started process to select the correct name to use, but if not perhaps it can at least retry a different bitness upon error. PsfRundll.exe is also a possibility to consider, but I think that you'd still need to modify code to look at the bitness of the started process.

Found issue with PsfLauncher on Anaconda (it is a huge app but the issue should be reproducable with any app needing multiple command line arguments in the config.json file). The process never tries to start.

It looks like the code in StartProcessHelper.h for the StartProcess case assumes no more than one argument present (Line 50 when initializing the arguments). This should be looked at, and while there the shell launch case should be reviewed as well.

I believe that the FileRedirectionShim should allow the json configuration tupple to be a triple that allows one to define a base for the relocation.

Redirecting everything to AppData/Local is not going to cut it. Some of the file data, especially user settings files, should be redirected to a place that follows the user (such as AppData/Roaming, home drive, or even OneDrive). One should be able to specify this in the json configuration.

We are going to use this to remediate the behaviors of apps that were doing the wrong thing. Please allow the flexibility for us to do so. IT Pros will not have the ability to modify the original application source. Without this flexibility in the FileRedirectionShim, we will be forced to continue to rely upon the AppCompatToolkit and skip the PSF.

Start menu items do not currently support command line arguments, so the PSFLauncher supports migrating them into the config.json file. This is good for the start menu, but there are situations where the same exe is used as part of a FTA, and the Shell command there will always add an argument to the file, and may specify additional arguments.

Currently, any command line arguments that show up on the launcher are ignored and only the specified ones in the config.json file are used.

I would suggest a change where the arguments to the launcher are looked at. If there are none, the code does what it does today. If there are any arguments, however, those should probably take precedence. I think that using those and ignoring those in the config.json is likely the best thing to do (as the result will be exactly what the original FTA wanted). If there are other situations, a flag asking to merge arguments when present (removing duplicates) could also be added.

In addition to FTA launches, this probably affects a URL Protocol launch for apps.

I have a software which consists of console programs that I want to package in MSIX and I am using windows.appExecutionAlias extension to make them visible to command prompt. And I also want to virtualize some file locations by FileRedirectionFixup to make it behave well in the MSIX container.

However, I noticed that PsfLauncher seems to be a desktop program and if I shim the console program by it, the standard I/O is no longer redirected to the original command prompt. Does anyone have experience the same situation? and hope I can get some pointers here.

We saw an issue in packaging up RStudio and using this fixup. The installer adds multiple copies of bit-specific dlls in different foldlers with the same name, and then chooses the folder on the basis of the running process, which might be either bitness depending on how the app was launched.

This fixup should add an optional field for the bitness of the dll in the config, and then check the bitness of the calling process when load library is called.

Since v1.0 of the configuration converter there have been more fixups added. The xsl file needs to be updated to support these new fixups.

To conform with the rest of PSF all instances of the word "Shim" in the PSFShimMonitor needs to be replaced with the word "Fixup"

Json element names are traditionally pascalCase. The main.cpp file line 58 checks for "WaitForDebugger" instead of "waitForDebugger" and therefore never waits.

This only affects the debug build, but is needed when you want to debug the launcher itself.

Issue moved from dotnet/sdk#18031

• Please respond to @lennartb-.

From @lennartb- on Wednesday, June 2, 2021 6:26:20 AM

Hello,

I hope this is the correct project for this problem. We're observing several issues when trying to package a .NET 5 application with a Windows Packaging project. I have build a minimal repro solution which can be found here: https://github.com/lennartb-/WpfMsixDemo

We're using Visual Studio 2019 16.10.0.

The first issues are a warning and and error right off the bat:

MSB4044	The "ProcessFrameworkReferences" task was not given a value for the required parameter "RuntimeGraphPath".	 MsixProject C:\ProgramFiles\dotnet\sdk\5.0.300\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets	63	

This is apparently the same as #17711.

The other error is stranger:

Warning	NU1702	ProjectReference 'C:\Users\lbrue\Source\Repos\WpfMsixDemo\WpfMsixDemo\WpfProject\WpfProject.csproj' was resolved using '.NETCoreApp,Version=v5.0' instead of the project target framework '.NETFramework,Version=v4.5.1'. This project may not be fully compatible with your project.	MsixProject	D:\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets	1717	

There are no references at all to 4.5.1, especially since the .wapproj doesn't have a target framework.

When trying to package the WPF project via right click on MsixProject -> Publish -> Create App Packages, and then "Sideloading", skipping signing, and these (default) settings:

We're getting:

Error		It is not supported to build or publish a self-contained application without specifying a RuntimeIdentifier. You must either specify a RuntimeIdentifier or set SelfContained to false.	MsixProject	C:\Program Files\dotnet\sdk\5.0.300\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.RuntimeIdentifierInference.targets	127	

Which seems to be the same as #151

If I add <RuntimeIdentifiers>win-x64;win-x86</RuntimeIdentifiers> to the WPF project and try to re-publish, I'm getting a different error:

There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "C:\Users\lbrue\Source\Repos\WpfMsixDemo\WpfMsixDemo\WpfProject\bin\x86\Debug\net5.0-windows\win-x86\WpfProject.dll", "x86". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.

Okay, this may have something to do with the fact that .NET5 apparently doesn't have the notion of AnyCPU? So we try to publish explicitly as Debug (x86), this time with a self-signed certificate created in the signing step earlier - this works now as expected. I can install the package via the generated Add-AppDevPackage.ps1 and run the app successfully.

In our actual project, the only configuration that we could run was Release (x86), other architectures would install but not start. In The event log, there were these errors:

Description: A .NET application failed.
Application: Contoso.Ide.Frontend.Wpf.exe
Path: C:\Program Files\WindowsApps\cebbfdbd-a176-41fd-a9ae-886ff49f406d_1.0.0.0_x64__4npsxfd6mepsr\Contoso.Ide.Frontend.Wpf\Contoso.Ide.Frontend.Wpf.exe
Message: Failed to load the dll from [C:\Program Files\WindowsApps\cebbfdbd-a176-41fd-a9ae-886ff49f406d_1.0.0.0_x64__4npsxfd6mepsr\Contoso.Ide.Frontend.Wpf\hostfxr.dll], HRESULT: 0x800700C1
The library hostfxr.dll was found, but loading it from C:\Program Files\WindowsApps\cebbfdbd-a176-41fd-a9ae-886ff49f406d_1.0.0.0_x64__4npsxfd6mepsr\Contoso.Ide.Frontend.Wpf\hostfxr.dll failed

Application: Contoso.Ide.Frontend.Wpf.exe
CoreCLR Version: 5.0.621.22011
.NET Version: 5.0.6
Description: The process was terminated due to an unhandled exception.
Exception Info: System.TypeInitializationException: The type initializer for 'System.Windows.Application' threw an exception.
 ---> System.TypeInitializationException: The type initializer for 'System.Windows.Navigation.BaseUriHelper' threw an exception.
 ---> System.TypeInitializationException: The type initializer for 'MS.Internal.TraceDependencyProperty' threw an exception.
 ---> System.BadImageFormatException: An attempt was made to load a program with an incorrect format. (0x8007000B)
   at MS.Internal.AvTrace.IsWpfTracingEnabledInRegistry()
   at MS.Internal.AvTrace.ShouldCreateTraceSources()
   at MS.Internal.AvTrace.Initialize()
   at MS.Internal.AvTrace..ctor(GetTraceSourceDelegate getTraceSourceDelegate, ClearTraceSourceDelegate clearTraceSourceDelegate)
   at MS.Internal.TraceDependencyProperty..cctor()
   --- End of inner exception stack trace ---
   at MS.Internal.TraceDependencyProperty.get_IsEnabled()
   at System.Windows.DependencyProperty.RegisterCommon(String name, Type propertyType, Type ownerType, PropertyMetadata defaultMetadata, ValidateValueCallback validateValueCallback)
   at System.Windows.DependencyProperty.RegisterAttached(String name, Type propertyType, Type ownerType, PropertyMetadata defaultMetadata)
   at System.Windows.Navigation.BaseUriHelper..cctor()
   --- End of inner exception stack trace ---
   at System.Windows.Navigation.BaseUriHelper.get_PackAppBaseUri()
   at System.Windows.Application.ApplicationInit()
   at System.Windows.Application..cctor()
   --- End of inner exception stack trace ---
   at System.Windows.Application..ctor()
   at Contoso.Ide.Frontend.Wpf.App..ctor()
   at Contoso.Ide.Frontend.Wpf.App.Main()

Is packaging a .NET 5 WPF app this way currently supported, or did we try something not yet completely ready?

I don't see any mention in the readme/documentation of the StartingScriptWrapper.ps1 file.

Also, if you create a package and forget to include the StartingScriptWrapper.ps1 file, there is no error shown, your specified script just fails to run. It would be helpful to people consuming this if there is more obvious indication that this was the problem.

A new installation of VS 2019 does not include the ability to install the Windows SDK 10.0 version any more, and most (all?) of the VS projects in this repsotory are configured to use it. (and VS 2022 is just around the corner!)

These projects should be updated to a newer version of the SDK. Currently 10.0.16299 is the oldest available. But given that MSIX isn't supported on that OS, perhaps a newer version should be selected? This sounds like an issue that Microsoft needs to decide.

We have discovered that some CRT versions use GetCurrentPackageId to determine whether the current process "is packaged", At least one of the ways that CRT behavior changes when running in a packaged process is thoroughly broken - it automatically initializes threads created via begin thread as MTA, assuming the app cannot initialize it any other way, so when the app tries to initialize it this fails. Other CRT behavior differences may be less disruptive, but in any case reverting them makes behavior consistent with the unpackaged case.

This sounds like a feasible fix for PSF .

The launcher ends up trying to start a process using an empty string. It should map this entry as relative to the root folder of the package, just like any other VFS path.

Note: This used to work, but there must be a bug.

The FRF contains logic such that if a folder exists in the package and the app tries to create a sub item (file or folder) then the item will be created in the local appdata "writablepackageroot" area. Under investigation is a potential issue for when the folder in the package is specifically the VFS folder.

For example, the package has the folder "VFS\ProgramFilexX64\Vendorname", but not "VFS\AppData". Currently it looks as if with this setup if the app attempts to create "%AppData%/vendorfolder", the FRF kicks in and creates this in the writablepackageroot (The app first opens %AppData%, which is adding VFS/AppData folder to the writable package root, and then the subfolder is created under it). While this would be desirable if there had been an AppData folder in the package, in the absence of it we would probably want the native write to occur. Likewise, other folders like LocalAppData and CommonAppData should probably also be adjusted.

Without the FRF in place (to solve problems with the ProgramFiles area), this app would have just written the files natively. Or maybe natively depending on the OS Runtime (which is why this needs more investigation) I think that the FRF should do the same as such files may need access.

While it would be possible to construct json rules to avoid this from happening, my preference is to allow one standard set of rules to work for most all applications that need the FRF.

Using the latest Visual Studio 2019 I am trying to publish a Msix installer for a DotNetCore 3.1 WPF application. The application builds and runs correctly, but when I try to publish my application I get this error

It is not supported to build or publish a self-contained application without specifying a RuntimeIdentifier.

My UI projects csproj looks like this.

<PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <UseWPF>true</UseWPF>
    <RuntimeIdentifier>win10-x64</RuntimeIdentifier>
    <SelfContained>false</SelfContained>
</PropertyGroup>

How can this issue be fixed?

The issue only occurs when I reference my self hosted asp.net core project from the gui project that I am trying to package.

What could be causing this issue? Are asp.net core projects just not supported to package that kind of project for some reason?

Again just to be clear.
The asp.net core project is referenced as a project reference by the wpf gui project. The wpf gui project self hosts the asp.net project. If I remove this reference (and the few lines of code that call into it) then it packages correctly.

"startScript": {
"scriptExecutionMode": "-ExecutionPolicy RemoteSigned",
"runOnce": true,
"showWindow": false,
"scriptPath": "CopyFile.ps1"
}

I believe that we will need a new fixup to control process launching. The scenario to support if apps that drop files temporarily into the user's temp folder and then try to run an executable external to the package against the file. Under the newer OS's this file is automatically redirected under the writablepackageroot (by the RUNTIME, not by the FileRedirectionFixup) and when the external program is launched (notepad.exe, for example), the external process starts outside of the container and the path given is not valid.

Adding an intercept to the launch that can be controlled via conf.json settings to indicate if the new process should be contained would solve this. To be determined if this is a new fixup or a mod to the intercept in place by PsfRuntime.

There are too many warnings in PSF. This could cause unforeseen errors in production.

When using PsfLauncher to start a process via shell launching (starting a native app by specifying a file with a given extension, like .txt or .pdf), the launch works great but PsfLauncher investigates the exit code of the process and will report an error via a popup dialog if not zero.

There are instances when the process returns non-zero exit codes, but it should be safe to assume that the application should have already informed the end-user of any issues if that is necessary. The launcher code should record the exit code for debugging purposes using logging.

I have a fix for this and will include in the next batch.

Many existing pieces of software already utilize a file named config.json. A less generic name would result in fewer collisions where PSF source has to be manually modified to look for a different name.

The identifiers for ETW tracing are AGAIN out of sync, causing PsfShimMonitor to not receive any events from the TraceFixup dll.

I have a fix for this, again, and will put in a PR once the others that I have are processed.

The non-shell launch case for PSF launching properly determines the working directory from the Json file, logs it is going to use it, but then does something else anyway. Simple fix needed.

The 1.0.200410.1 nuget version has a crash issue in GetPrivateProfileStringFixup (FileRedirectionFixup) . Call stack is

`0:020> kL

 ChildEBP RetAddr      

00 06fcdae0 767c04ab FileRedirectionFixup32!GetPrivateProfileStringFixup+0x4d0
01 06fcdb00 6e62429e kernel32!GetProfileStringW+0x1b
02 06fcde5c 6e62557d winmm!mciLoadDevice+0x2d5
03 06fcde9c 6e620a28 winmm!mciOpenDevice+0x2c5
04 06fcdeb4 6e620805 winmm!mciSendSingleCommand+0x1ba
05 06fcdeec 6e6220e4 winmm!mciSendCommandInternal+0x12b
06 06fcdf1c 0a22f94a winmm!mciSendCommandW+0x84`

This commit contains that fix. The Nuget should be updated.

Application (Calibre) runtime calls set working directory to set it to a subfolder of it's installation folder. The app is believed to do this to aid in dll loading. As the app requests the native path (C:\Program Files\Vendor\subfolder) that it stored into the registry upon install, this folder does not exist, SetWorkingDirectory fails and the app fails.

In this situation, the FRF should have additional intercepts that cause this app call to be redirected to the equivalent VFS folder under the package root. I believe this code should first see if the requested folder exists and do what it asked, and then only look for the package VFS equivalent if that fails. This would better handle other potential situations such as the app requesting the System32 folder as attempts to use this CWD in other file operations will find both the native and package VFS files later on.

In addition to adding support to the FRF, support should also be added to TraceFixup.

The codebase currently uses these copyright headers:

//-------------------------------------------------------------------------------------------------------
// Copyright (C) Microsoft Corporation. All rights reserved.
// Licensed under the MIT license. See LICENSE file in the project root for full license information.
//-------------------------------------------------------------------------------------------------------

Because the Microsoft CLA does not facilitate or require transfer copyright, copyright may belong to a number of contributors. There is no guidance on how contributors should be added to the header.

Do we add them after the Copyright (C)? What ordering scheme do we use? First name/Last name/Significance?

Alternatively, and contributors could be added:

//-------------------------------------------------------------------------------------------------------
// Copyright (C) Microsoft Corporation and contributors. All rights reserved.
// Licensed under the MIT license. See LICENSE file in the project root for full license information.
//-------------------------------------------------------------------------------------------------------

The .NET Foundation takes a similar approach.

Calls to GetPrivateProfileSection with null filename causes the fixup and app to crash.

I would suggest updating

to use widen_argument

FileRedirectionFixup includes two intercepts for ProfivateProfiles (a set of functions associated with reading/writing ini files). Intercepts are needed for the remaining functions as well. These include

• GetPriviateProfileNames
• GetPrivateProfileSection
• GetPrivateProfileInt
• GetPrivateProfileStruct
• WritePrivateProfileSection
• WritePrivateProfileStruct

Bonus points awarded for also adding support into TraceFixup for these 6 functions and the two already supported in the FRF.

I have a .netcore 3.1 WPF app and I'm using a MSIX packaging project through visual studio for distribution. Is it possible to add PSF to a .netcore 3.1 app?. Basically what I'm trying to do is, I want the MSIX installer to add a desktop shortcut automatically after the installation is done.
This is the approach I'm following: https://docs.microsoft.com/en-us/windows/msix/psf/create-shortcut-with-script-package-support-framework

I also found this guide on how to add PSF to visual studio: https://docs.microsoft.com/en-us/windows/msix/psf/package-support-framework-vs. It uses a c++ project to run a .dll, but I think that's only compatible with .net framework and it's not compatible with .netcore. Can anyone please help me?

Both the FileRedirectionFixup and RegLegacyFixup crash when initializing is bad regex patters are provided in the config.json file.

For example, the FRF calls pattern.assign in the InitializeConfiguration section unprotected.

Passing a string like
.\xml
instead of the correct syntax
.\.xml
causes the crash.

This code should be protected and bad patterns ignored after logging.

When I run the application exe file directly from C:\Program Files\WindowsApps it works, but not when I start it from the Start menu.
Process Monito is showing C:\WINDOWS\Microsoft.Net\assembly\GAC_32\Microsoft.ReportViewer.WinForms\v4.0_14.0.0.0__89845dcd8080cc91\Microsoft.ReportViewer.WinForms.dll PATH NOT FOUND. NuGet package is Microsoft.ReportingServices.ReportViewerControl.Winforms. Why is he looking there when files are in an app directory? I am using .NET Framework 4.8 WPF and WindowsFormsHost for displaying the ReportViewer. From an explanation of how Package Support Framework works, I still don't know what exact steps should I take or if what process monitor shows is the root problem.

Update:
When I run PsfLauncher32.exe it throws this error:
"Faulting application name: PsfLauncher32.exe, version: 0.0.0.0, time stamp: 0x5e66e34c
Faulting module name: PsfRuntime32.dll, version: 0.0.0.0, time stamp: 0x5e66e338
Exception code: 0xc0000409
Fault offset: 0x00028bd1
Faulting process id: 0x5dc8
Faulting application start time: 0x01d5fa3f846ea6ca
Faulting application path: C:\Programming\SyriliumRiF\Main\SyriliumRiF.MSIX\bin\x86\Release\PsfLauncher32.exe
Faulting module path: C:\Programming\SyriliumRiF\Main\SyriliumRiF.MSIX\bin\x86\Release\PsfRuntime32.dll
Report Id: 1f39b072-5917-486f-abc1-21712ebdc372"

I have a fix for this. The PR will be issued once PR124 and the one that will follow for issue #125 are processed.

https://github.com/microsoft/MSIX-PackageSupportFramework/blob/master/README.md the documentation in the table for scriptPath says "The path to the script including the name and extension. The Path starts from the root directory of the application."

This could be more accurately stated that the path is relative to the application's working directory if specified, otherwise, it starts at the root directory of the package

Regarding the problem "Executing a packaged app with the wrong current working directory" that requires a fixup to address if the application previously had a shortcut that set the working directory.

The ShimLauncher should support a way that we can specify a working directory for the target process in the AppXManifest, or AT THE MINIMUM, assume that the directory that the target exe is run from should be set as the working directory when the ShimLanucher starts the new process. It should never assume the system folder.

The JSON entries for scripting allow for a single "argument list" to be enclosed in quotes.

I have seen an issue where one of the arguments was a variable but referenced the user name (profile path) and failed for a user with username that included a space because the command interpreted it as "argu ment list" rather than "'argu ment' 'list'".

This might suggest the need to update the Json structure for the argument, or improved guidance on creating the scripts.

Application crash when executing crystal report in MSIX.

{
"processes": [
{
"executable": ".",
"fixups": [
{
"dll": "FileRedirectionFixup",
"config": {
"redirectedPaths": {
"packageRelative": [
{
"base": "",
"redirectTargetBase": "C:\ProgramData\",
"patterns": [
".\.log"
]
}
]
}
}
},
{
"dll": "TraceFixup",
"config": {}
}
]
}
]
}

Faulting application name: CrystalReportsApp.exe, version: 1.22.0.0, time stamp: 0x5f9ab37c
Faulting module name: FileRedirectionFixup64.dll, version: 0.0.0.0, time stamp: 0x5f69a7ed
Exception code: 0xc0000005
Fault offset: 0x000000000000f3f3
Faulting process id: 0x369c
Faulting application start time: 0x01d6adf10c87ff47
Faulting application path: C:\Program Files\WindowsApps\ReportApp_1.0.3.0_x64__vd2wza2a776vr\CrystalReportsApp.exe
Faulting module path: C:\Program Files\WindowsApps\ReportApp_1.0.3.0_x64__vd2wza2a776vr\FileRedirectionFixup64.dll
Report Id: c5e01333-8faf-4540-a774-a8879d0c651e
Faulting package full name: ReportApp_1.0.3.0_x64__vd2wza2a776vr
Faulting package-relative application ID: ReportApp

config.json.txt

When tracing a package using the FRF by using ProcessMonitor, we often see attempts to access using paths like:
C:\Users\XXX\Local\AppData\Packages\YYY\LocalCache\Local\Microsoft\WritablePackageRoot\VFS\Local AppData\...

Most of the time these things don't get found and the FRF functions move on, but sometimes I see something getting created and later on the application tries to use it and can get confused and fail.

The ShouldRedirect function should not return a redirection path to something input into the function under WritablePackageRoot.

GetDiskFreeSpaceEx A/W
GetDiskFreeSpace A/W
GetCompressedFIleSize A/W
GetFullPathName A/W
GetTempFileName A/W
GetShortPathName A/W
GetLongPathName A/W

FindFirstFileName A/W
FindNextFileName (because may need 3 layer data struct also)
FindFirstStream W only
FindFirstChangeNotification A/W
FindNextChangeNotification (because may need 3 layer data struct also?)

Hi,

I am seeing a problem with the PSF launcher where it uses the working directory of an MSIX shortcut to locate the StartingScriptWrapper.ps1 file. I have had this confirmed by Tim Mangan and Darren Hoehna. I am seeing the problem when I use PSF Tooling and Advanced Installer Express.

In certain badly formed packages that are using the PSF using VFS pathing, the PsfLauncher might crash with a complaint about directory enumeration with operator ++.

There are three possible cases that need to be addressed:

• when finding the config.json file
• when finding PsfRuntime.dl
• when finding fixup dlls.

The test to prevent redirection to something already redirected checks the return incorrectly.

I have a fix for this.

It would be helpful to include in the documentation something on Priority of the json configuration list.

As an example, in the FileRedirectionShim json example file, if the app wrote to App to Logs\Log.txt instead of the example, I am guessing that the json configuration is processed serially from the top and as soon as a rule matches, further processing down the list stops. Thus it only matches once using the Base=Logs rule.

If so, mentioning that the list is prioritized from top to bottom in that documentation will make it easier for people to understand that concept.

In order to use the PSF with the Microsoft MSIX Packaging Tool, it is necessary to specify the installation folder and install into that folder, rather than a "VFS" style install that we usually prefer. This is because PsfRuntime only looks in the Root folder of the package for the config.json file.

This could be resolved by first looking in this location, but then failing to find it look in the folder containing the running exe (or perhaps current working directory since that is easier in C++) when not found. It might be that we'll have some issues with placement of the PSF dlls also in VFS styling, so I'm just opening this as an issue at this time.

In a VFS style package, it might be better to declare a standard VFS folder for all of the Psf components instead. Needs more thought...

While applications usually load dlls using relative paths, sometimes they call with full path information.

DynamicLibraryFixup does not support the full path case where the location of the full path has moved. When written, it was incorrectly assumed the file redirection in the MSIX runtime would cover this case, but it does not.

This fixup should look at the filename only to determine if a internal dll file exists.

j'ai fais tout le configuration concernant l'application mais elle ne se lance plus lors de declencher le commande "npm start" ceci le message que s'affiche sur git Bash :
$ npm start

[email protected] start C:\Users\borem\Desktop\a2website
tsc && concurrently "npm run tsc:w" "npm run lite"

node_modules/rxjs/Subject.d.ts:24:5 - error TS2416: Property 'lift' in type 'Subject' is not assignable to the same property in base type 'Observable'.
Type '<T, R>(operator: Operator<T, R>) => Observable' is not assignable to type '(operator: Operator<T, R>) => Observable'.
Type 'Observable' is not assignable to type 'Observable'.
Type 'T' is not assignable to type 'R'.

24 lift<T, R>(operator: Operator<T, R>): Observable;
~~~~

node_modules/typescript/lib/lib.d.ts:105:14 - error TS2300: Duplicate identifier 'PropertyKey'.

105 declare type PropertyKey = string | number | symbol;
~~~~~~~~~~~

typings/globals/core-js/index.d.ts:3:14 - error TS2300: Duplicate identifier 'PropertyKey'.

3 declare type PropertyKey = string | number | symbol;
~~~~~~~~~~~

npm ERR! code ELIFECYCLE
npm ERR! errno 2
npm ERR! [email protected] start: tsc && concurrently "npm run tsc:w" "npm run lite"
npm ERR! Exit status 2
npm ERR!
npm ERR! Failed at the [email protected] start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR! C:\Users\borem\AppData\Roaming\npm-cache_logs\2020-10-24T10_02_10_583Z-debug.log

Reported via customer.

Customer used the Microsoft QuickCreate Windows 10 VM for Developers and attempted to install and run a package that used the PSF for a start of application script. The script does not run (and therefore the app does not run either).

If appears that the PSF looks for HKLM\SOFTWARE\Microsoft\PowerShell\1 key for a DWORD value called Install as a means to determine if PowerShell is installed. PowerShell is installed but the 1 key is not present (the 3 key is).

I believe that the Psf should use another method to determine if PowerShell is installed.

Many of the more interesting Start Scripts that I want to write require the script to know what the root folder of the package is so that files can be located. For example, a first run script might involve looking for configuration files under the package VFS/AppData or LocalAppData folder(s), then checking to see if native equivalent files exist (from an older non-MSIX install), and copying from the non-MSIX or package source as appropriate into the package redirection folder.

So I would like to see the "arguments" field of the script definition in the json to be able to specify a pseudo-variable, such as %PackageRoot% and have the Psf Script processing replace that with the value of g_PackageRootPath.

This would allow a generic script for that purpose, which uses arguments for the root folder and relative specific file paths. This script could then be used for any package, no matter how it is built.

This causes application crashes when the OS attempts to apply certain appcompat shims.

PSF should only pass the EXTENDED_STARTUPINFO_PRESENT flag when the StartupInfoEx structure lpAttributeList is non-null and initialized.

Every class has more or less the same code to log information. All this code should go into one file.