Forum Widgets
Latest Discussions
Add Environment Variable to MSIX package using PSF Fixups in Packaging Tool - what am I missing?
Hi everyone, I am currently testing packaging apps into the MSIX format and have been successful for any simple installers. Now that I am trying to package more advanced installers I have to utilize PSF Fixups, in which I have issues with the Environment Fixup. Even though I have read up on previous discussions regarding this, I simply cannot get this fixup to be successfully added and recognized within the MSIX App. I am judging this based on that the same app will tell in its own app options whether the environment variable is available or not. Some key info (Tried attaching several screenshots, but it wilI not let me. Hopefully the necessary information comes across): Using MSIX Packaging Tool version 1.2024.405.0 Using the included PSF Fixup for Environment Variables within MSIX Packaging Tool. All PSF Fixup files are included in the MSIX Package. In the manifest file the executable "PsfLauncher64.exe" is pointed at. Basically, the config.json is formatted in the following way if I were to change out anything referring to the actual app name. What am I possibly missing out on or have misunderstood here? Any help in leading me into the right direction is very much appreciated, thanks!Removal of an AppX/MSIX package leaving unwanted clutter in the user registry.
MSIX is supposed to be a clean uninstall. However, I have some detected some unnecessary garbage left behind when uninstalling under HKCU\Software\Classes. Take a package and install it. Then Uninstall it. Repeat that a few times. Open Regedit. Browse to HKCU\Software\Classes. Do a find on the package name,. You will find there is a key starting with AppX (followed by random looking letters) with subkeys Application, DefaultIcon, and possibly Shell. These were added during the installation of the package. Keep searching (F3). You will find the same information under an AppX... key for each package you originally installed. This does not appear to be due to delayed removal, as they remain weeks or months later.
Appx Package Leaves Behind DLLs on Uninstall (Pipeline vs Local Debug Build)
Hello everyone, I'm encountering an issue with my WPF application that's packaged as an appx file for sideloading. I'm new to this area, so any guidance or suggestions would be greatly appreciated. Issue Overview: Pipeline Build (Release): The appx package generated in our build pipeline (with code signing) installs and runs as expected. However, after uninstalling the app, certain DLLs remain in the Windows app folder. Local Build (Debug): When I generate the appx package locally using Visual Studio in Debug mode and perform the install/uninstall on the same device, the DLLs are cleaned up properly. I didn't changed any property in the appxmanifest.xml other than the publisher name and the certificate.
Self-Signed Certificate in User Store Causes MSIX Installation Error
I created a self-signed certificate by following the official documentation provided https://learn.microsoft.com/en-us/windows/msix/package/create-certificate-package-signing The documentation instructs users to add the self-signed certificate to the current user's certificate store like so: New-SelfSignedCertificate -Type Custom -Subject "CN=Contoso Software, O=Contoso Corporation, C=US" -KeyUsage DigitalSignature -FriendlyName "Your friendly name goes here" -CertStoreLocation "Cert:\CurrentUser\My" -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.3", "2.5.29.19={text}") However, when the certificate is added to the user-specific certificate store (Cert:\CurrentUser\My), attempting to install the signed msix file produces the following error: This app package’s publisher certificate could not be verified. Contact your system administrator or the app developer to obtain a new app package with verified certificates. The root certificate and all immediate certificates of the signature in the app package must be verified (0x800B010A). I had to resolve this by adding the certificate to the local machine certificate store (Cert:\LocalMachine\TrustedPeople) instead. Does anyone have insights into why adding the certificate to the user-specific store causes the aforementioned issue, despite this being what's suggested in the documentation?
How to convert msix to msi?
Hello, I am currently working with a Windows application packaged as an .msix file, which is used for connecting to Azure Virtual Desktops (AVD). I need to convert this .msix package to an .msi package. Additionally, I am looking for a way to convert a Microsoft Store app into an .msi package. Challenges: Converting MSIX to MSI: I need a reliable method or tool to convert the existing .msix file to an .msi file without using Advanced Installer (didn't work). Microsoft Store App to MSI: I also need guidance on how to package a Microsoft Store app as an .msi. If anyone is familiar with these processes, especially in the context of the windows app (yes there is an app named "windows app"), your help would be greatly appreciated. Thank you!
MSIX appinstaller UpdateSettings
I have an MSIX and associated appinstaller file. Within the AppInstaller I have various Update settings such as OnLaunch / HoursBetweenUpdateCheck =0, ShowPrompt=true and automaticBackgroundTask. When I install the app using the appinstaller, this works, and the app launches. If I then close the app, and try to launch it again, the appinstaller prompt is launched, but with the message "Cannot Open App Package : failed due to unknown reason". In logs, I have the message "Error code: Activation is blocked due to the .appinstaller update settings for this app.. Activation phase: Deployment". Anyone come across anything like this? I have tried changing the AppInstaller Uri and the MainPackage Uri to local files (C:), mapped network drives and UNC paths. But the same appinstaller works for the initial installation, then fails on the update check.
Understanding App Isolation Behavior in MSIX: Issue with System State Restoration After Crash
We have an application built with .NET Forms, while the security components (DLLs) are developed in C++. Recently, we packaged our application using MSIX (App Isolation) and signed it with a self-signed certificate. The Application launches and functions as expected. However, when we introduce an intentional crash (e.g., a null pointer exception), the system does not restore the changes made by the application, such as hiding the taskbar. Our understanding was that App Isolation would help revert any system modifications after a crash, but it seems this isn't the case. Is this expected behavior for App Isolation in MSIX, or are we missing something in our configuration? Any insights on ensuring system state restoration would be appreciated.Understanding App Isolation Behavior in MSIX: Issue with System State Restoration After Crash
We have an application built with .NET Forms, while the security components (DLLs) are developed in C++. Recently, we packaged our application using MSIX (App Isolation) and signed it with a self-signed certificate. The Application launches and functions as expected. However, when we introduce an intentional crash (e.g., a null pointer exception), the system does not restore the changes made by the application, such as hiding the taskbar. Our understanding was that App Isolation would help revert any system modifications after a crash, but it seems this isn't the case. Is this expected behavior for App Isolation in MSIX, or are we missing something in our configuration? Any insights on ensuring system state restoration would be appreciated.
bugs of MSIX packaging tool PSF feature
Hi, Guys I once opened a question this September, regarding the PSF Environment Variable fixup issue. As nobody replied the thread, I revoked it, and started to investigate the issue by myself in free cycles. 3 weeks ago, I found the root cause of the issue. Trying to explain the detail here. Initially, To test the environment variable fixup, I created a Powershell2exe exe by converting below powershell script into an exe. [void] [System.Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms") [System.Windows.Forms.MessageBox]::Show("The Environment variable %MSIX% has the value of ${env:msix}") After reading PSF readme, I realized that the Poweshell2Exe solution doesn't work with PSF fixups. The Environment Variable fixup can only intercept the API of GetEnvironmentVariable from kernel32, also doesn't support API GetEnv from VC runtime. I set up a least simple test environment (my job role doesn't have the access to full visual studio IDE, so just download the VS build tools which include the c/c++ compile/link exes and the windows SDK), cl.exe and those static libs are good enough to build a test exe which can retrieve the environment variable by calling GetEnvironmentVariable. Unfortunately, the test Exe still doesn't work with the PSF Environment Variable Fixup . By using the debugView to collect the PSF log output, you can find that the last log info we can get comes from the psfruntime routines (config.cpp\load_json), we don't see any log comes from Environment variable fixup after that. This log info did mislead me too much, it made me believe that there is sth wrong in the psfruntime, not from the fixup dll. I kept trying to locate the issue from PSFRuntime with no good, until I use my test environment to add GetLastError to the suspicious BP, which tells me that the Environment variable fixup dll (EnvVarFixup32.dll) failed in initializing itself. I then found that the EnvVarFixup32.dll comes with the MSIX packaging tool had disabled all the log output, and that is why we don't see any fixup dll log from DebugView. Replace the original one with the rebuild one. With the rebult dll logs support, I can locate the issue to the code InitializeFixup.cpp\ InitializeConfiguration This is the MSIX Packaging Tools generated config.json file. The above code treats the attribute as string type. But the generated json file treat it as Boolean type. Apply the double quotation marks to the value, test the MSIX pkg again, Issue SOLVED. Last week, I also reviewed the DLL redirection fixup when I have free cycle. There is a similar bug for the DLL redirection fix. Below is the MSIX packaging tool generated json file. You can see this time the auto generated json file sets the attribute "forcePackageDllUse" as a string value. Unfortunately, the DLL redirection fix up (DynamicLibraryFixup32/64.dll) reads it as a Boolean value. So, this time all you need to do is REMOVING the double quotation mark, or you will get the same DLL initialization error. During the investigation of the DLL redirection fixup, I realize that there is limitation from the detour, the tech PSF uses to intercept the windows API calls. I can see some types of the exe files are not compatible with the detour. eg, IBM lotus Organizer. (Org6.exe). I also found that some sites gave out incorrect json sample file, eg, "filepath": "\\VFS\\ProgramFilesX86\\MSIXPSF\\DLLRedirect\\dll\\PSFDll.dll", this path pattern will not work. The dll path will not redirect to your expected path PsfPkgRootPATH\\VFS\\ProgramFilesX86\\MSIXPSF\\DLLRedirect\\dll\\PSFDll.dll. std::filesystem::path operator "\" will give out the value as "c:\\VFS\\ProgramFilesX86\\MSIXPSF\\DLLRedirect\\dll\\PSFDll.dll" instead. I use MSIX packaging tool (1.2024.405.0) to create above MSIX test packages. Due to company policy, I don't have MS Store access, so can't test the 1.2024.508.0 from MS Store, if 1.2024.508.0 still has the bugs I mentioned above, please fix them asap.
