Forum Widgets
Latest Discussions
Unable to package Skype with the MSIX Packaging Tool using the provided template
Hi, I have this Skype application with me, and a given packaging template with the following properties: <PrepareComputer DisableWindowsSearchService="true" DisableWindowsUpdateService="true" /> <SaveLocation PackagePath="C:\ProgramData\Tools\MSIXPackagingWorkspace\Skype Technologies S.A._Skype_8.110.0.218.msix" TemplatePath="C:\ProgramData\Tools\MSIXPackagingWorkspace\Skype Technologies S.A._Skype_8.110.0.218.xml" /> <Installer Path="C:\Users\mhb\Desktop\Skype\Skype-8.110.0.218.exe" Arguments="/SP- /VERYSILENT /SUPPRESSMSGBOXES /NORESTART" /> <PackageInformation PackageName="Skype" PackageDisplayName="Skype Technologies S.A._Skype_8.110.0.218" PublisherName="CN=AppMPackageCertv2" PublisherDisplayName="Skype Technologies S.A." Version="8.110.0.0" p4:PackageDescription="Description" xmlns:p4="http://schemas.microsoft.com/msix/msixpackagingtool/template/1910" /> But while letting the MSIX Packaging Tool run the installer, it doesn't seem to stop and the tool keeps running indefinitely as we can see in the logs: Even though we can see that Skype actually has installed successfully in the background... The original installation command was: "Skype-8.110.0.218.exe" /SP- /VERYSILENT /SUPPRESSMSGBOXES /NORESTART P.S. Running the tool manually lets the installer finish successfully and I can progress to the next steps Am I missing something?
PsfLauncher64.exe ~ The system cannot find the file specified
Hello All, We use the Package Support Framework on some our applications shipped with MSIX to run some post installation scripts. We have had a few users that have gotten the above error when the application launches after installation. Please excuse the German; it translates to "The system cannot find the specified file". We are unfortunately unable to reproduce the issue on any of our machines/virtual-machines and haven't been able to figure out what is going on with this small minority of users. My only hunch is that there is some incompatibility with their PowerShell versions or system architecture. We have made it clear that our application only runs on x64 architectures, as we have not included the PSF 32-bit executables and libraries along with the MSIX package. Is it possible that some people can be running windows on x64, but require 32-bit versions of PSF? If so that is an easy fix but I haven't been able to confirm. Any help/information would be much appreciated. If it is not something we can fix on our side of things I would like to at least help these users get the issue resolved through our support process. Thanks in advance!Error signing app package with certificate from Azure Key Vault
Hello, we have a new (EV) code signing certificate stored in Azure Key Vault. Signing any of our [installer].exe files with the AzureSignTool.exe via command line, for example, is no problem. However, when it comes to signing any of our Windows application packages (*.msix), the signing fails (via VS or via command line). Signing via VS When we publish our app in VS, we can select our certificate directly from Azure: Signing then fails with the following error message: What is noticeable is that Identity.Publisher in the Package.manifest file has been replaced with: “CN=GlobalSign GCC R45 EV CodeSigning CA 2020, O=GlobalSign nv-sa, C=BE”. This string matches the Issuer of our certificate, but not the subject. Is that how it's intended? Nevertheless, when we disable automatic signing with (AppxPackageSigningEnabled = false) and replace Identity.Publiser with the subject of our certificate ("CN=3D.aero GmbH,, ST=Hamburg, ..."), validation fails with error message: "Validation error. error C00CE169: App manifest validation error: The app manifest must be valid as per schema: [..]". We have found out that the RegEx does not allow an ST key during validation. So we replaced it with S and building completes. Signing via command line However, if we then try to sign the built MSIX package with the AzureSignTool.exe via command line, this fails with the following error message: "The Publisher Identity in the AppxManifest.xml does not match the subject on the certificate." We assume this is due to the ST <> S problem? When using “CN=GlobalSign GCC R45 EV CodeSigning CA 2020, O=GlobalSign nv-sa, C=BE” manually, AzureSignTool also fails with the same message. Questions Why does signing fail if the certificate was automatically selected via the wizard? his string matches the Issuer of our certificate, but not the subject. Is that how it's intended? The RegEx for the validation of Identity.Publisher does not allow ST, can this be fixed?MSIX Packageing Tool / signtool certificate issues
1) I have a valid (paid for) code signing certificate from a well known CA that has a password so I can't use the in tool signing (which is something you should support!). The 17134 SDK is present. So I pulled the command out of the log file and modified as follows (but with the proper password): "C:\Program Files (x86)\Windows Kits\10\bin\10.0.17134.0\x64\signtool.exe" sign /a /v /debug /fd SHA256 /f "C:\Users\Admin\Desktop\strongname.pfx" /p "xxxThePasswordxxx" "C:\Users\Admin\Desktop\TMEdit\Setup_TMEdit.msix" Which fails. The relevant output being: After EKU filter, 1 certs were left. After expiry filter, 1 certs were left. After Private Key filter, 1 certs were left. The following certificate was selected: Issued to: TMurgent Technologies, LLP Issued by: COMODO RSA Code Signing CA Expires: Mon Jun 21 19:59:59 2021 SHA1 hash: A5CD580A89C438FB9B87753BB05F383560EB366F The following additional certificates will be attached: Issued to: COMODO RSA Code Signing CA Issued by: COMODO RSA Certification Authority Expires: Mon May 08 19:59:59 2028 SHA1 hash: B69E752BBE88B4458200A7C0F4F5B3CCE6F35B47 Done Adding Additional Store SignTool Error: An unexpected internal error has occurred. Error information: "Error: SignerSign() failed." (-2147024846/0x80070032) #2 Reading up on this we get to cause of issue number 2: The name of the publisher in CN form in the manifest (input from the MSIX Manifest tool) must exactly match that of the certificate: Inside the certificate, The publisher name is CN=TMurgent Technologies, LLP which, unfortunately, is the legal name of the entity so that isn't changing! The MSIX Package Tool does not allow a comma in the input field.
MECM Supersedence issues with resigned MSIX packages
Without access to a time stamp server solution, we've needed to re-sign a selection of MSIX packages deployed to windows 10 devices with a new code signing certificate previously. That time has come around again and thinking ahead as we prepare for windows 11, we know the list of packages will increase as we convert more AppV packages, a review of the MSIX toolkit has been started. A couple of observations, I'll also place on the github issues list, perhaps somecan provide feedback and sights in to. jvintzel Firstly the packages get updates with the new certificate and publisher information as checked using the get-appxpackage cmdlet; however the publisherid is not substituted in the msix package name as per the MPT default naming standard when saving msix packages, so these have needed to be renamed with another powershell script afterwards. Secondly, we have seen some unexpected results when deploying the resigned packages via MECM targeting the previously signed application with supersedence rules to swap the packages around without an application version update. Scenarios where with the uninstall tick box selected the previous package is removed but MECM doesn't proceed to attempt to install the new replacement package. Or the uninstall selection is not made an the update results in the new package passing for detection but leaving only the previous package actually installed. Whilst I know some of this could be added to a MECM community thread, any shared experiences with using the toolkit would be welcome.
msix HKLM key not read
I have an issue with my repackaged MSIX. A HKLM key under WOW6432node with my servername is not read. when i open the CMD within the bubble and i start the program, the key is read. But when starting it with the Shorcut it doesn't. Tried several PSF fixes but still not working, anyone an idea? thanks
AppInstaller OnLaunch Update check does not start the application after update
Hello We are currently developing an application that needs to check updates before launch. Therefore we implemented the following Appinstaller: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <AppInstaller Uri="https://somehost/someappinstaller.appinstaller" Version="1.0.1.36" xmlns="http://schemas.microsoft.com/appx/appinstaller/2018"> <MainPackage Name="SomeCompany.SomeApp" Version="1.0.1.36" Publisher="CN=Somepublisher" Uri="https://somehost/someupdatedpackage.msix" ProcessorArchitecture="x86"/> <UpdateSettings> <OnLaunch HoursBetweenUpdateChecks="0" ShowPrompt="true" UpdateBlocksActivation="true"/> <AutomaticBackgroundTask/> <ForceUpdateFromAnyVersion>true</ForceUpdateFromAnyVersion> </UpdateSettings> </AppInstaller> If we now have version 1.0.0.37 of SomeApp installed a window will show up to guide us to update the app: If i now click update the app will update but it will not start afterwards. The Eventlog is showing Eventlog Id 323 with error 0x80070490 reference the old version of SomeApp:Fehler 0x80070490: Das Paket "SomeCompany.SomeApp_1.0.0.37_x86__wpr0009ygztjt" kann not be registered: Element not found. When I try to launch the app using it's app alias with the command line I get the following error This message is basically saying that the file could not be accessed but what troubles me most that the path is pointing to version 1.0.0.37 so the version which has been replaced by the update. My fear is the following: The appinstaller has currently a bug which is not pointing to the outdated file after update. So the app will not launch after an update. Or am I using something wrong here?Eclipse IDE MSIX
Hello Anyone with experience creating a user context MSIX for Eclipse IDE to be deployed true App Attach for Azure Virtual Desktop. I have built a MSIX for Eclipse and ended up bringing the Installer process to the app attachment and not the application. All files are under the user context, and that is not working in a multitenant vm. Any ideas or tips. Thank youUploaded MSIX has generic errors
I have generated a MSIX for my Delphi App, which runs perfectly locally. It passes all the blocking Windows App Store Cert issues. When I upload it for the App Store, I get a series of generic error messages: * You must upload at least one package. If you are using market groups, then each market group must have at least one package (clearly I am) * You must provide a package that supports each selected device family (or uncheck the box for unsupported device families). Note that targeting the Xbox device family requires a neutral or x64 package (I have selected Windows 10/11 Desktop, and the AppManifest.xml specifies <TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.17763.0" MaxVersionTested="10.0.22000.1" /> * The package ***.msix is taking a long time to process. If this isn’t completed soon, try refreshing the page, or remove the package and then upload it again. If you continue to see this issue, contact support (seems to be because of earlier errora0 * You must fix all package validation errors before submitting (cascade failure). Can anyone advise on what the actual error might be?
