User Profile
TIMOTHY_MANGAN
MVP
Joined May 13, 2018
User Widgets
Recent Discussions
Re: Publish Java application to Microsoft Store
tommerfrancis I interpret your question as "how do I publish an application that uses Java to the Microsoft Store". While doing so is straight forward as far as putting the package together, unless you have a redistribution license for a Java to embed in your package, your package would not work without a compatible version of Java installed on the customer system. The Microsoft store does not have a good way for you to trigger this, nor do I think there would be sufficient notice to someone on the store page that they would understand that need. Possibly, you could add a front end launcher (not written in java) to your main exe that looks to see if a Java is present and prompts the user to find, download, and install it. You would not be able to have that program perform the installation as it is running inside the container. But generally, store apps do not contain dependencies like this as consumers are not good at handling it.Microsoft MSIX Packaging Tool Fails to create package due to AppXManifest (Typelib/Version/LibFlag)
The MMPT will fail to save the package after capturing an installation of Altova XmlSpy Enterprise. This is due to the MMPT reading a reading a registry string value for a Com Version and adding it into the AppXManifest in an incorrect form that violates the COM schema extension validation ST_VersionCom. The error from the MMPT log: [11/10/2025 11:17:46 AM] [Debug] MakeAppx : error: Failure at packageWriter2->Close( manifestStream, contentGroupMapStream.Get()) - 0x80080204 - The specified package format is not valid: The package manifest is not valid. [11/10/2025 11:17:46 AM] [Debug] MakeAppx : error: Error info: /*[local-name()="Package" and namespace-uri()="http://schemas.microsoft.com/appx/manifest/foundation/windows10"]/*[local-name()="Extensions" and namespace-uri()="http://schemas.microsoft.com/appx/manifest/foundation/windows10"][1]/*[local-name()="Extension" and namespace-uri()="http://schemas.microsoft.com/appx/manifest/com/windows10"][1]/*[local-name()="ComInterface" and namespace-uri()="http://schemas.microsoft.com/appx/manifest/com/windows10"][1]/*[local-name()="TypeLib" and namespace-uri()="http://schemas.microsoft.com/appx/manifest/com/windows10"][2]/*[local-name()="Version" and namespace-uri()="http://schemas.microsoft.com/appx/manifest/com/windows10"][1]/@LibraryFlag [11/10/2025 11:17:46 AM] [Debug] '#0' violates pattern constraint of '[0-9a-fA-F]'. [11/10/2025 11:17:46 AM] [Debug] The attribute 'LibraryFlag' with value '#0' failed to parse. [11/10/2025 11:17:46 AM] [Debug] Cleaning up output file "\\?\%UserProfile%\Desktop\Altova-XmlSpy_28.0.0.0_x64__xwfzvwzp69w2e.msix". [11/10/2025 11:17:46 AM] [Debug] MakeAppx : error: Failure at (CreatePackage( overwrite, hashAlgorithm, fileList, outputPath, manifestStream.Get(), forceCompressionNone, performanceOptions, encryptPackage, encryptionOptions, cgmPath, mainPackagePathForResourceExemption, makepriExeFullPath)) - 0x80080204 - The specified package format is not valid: The package manifest is not valid. [11/10/2025 11:17:46 AM] [Debug] MakeAppx : error: Package creation failed. [11/10/2025 11:17:46 AM] [Debug] MakeAppx : error: 0x80080204 - The specified package format is not valid: The package manifest is not valid. [11/10/2025 11:17:46 AM] [Error] MakeAppx.exe failed, exit code = 1 [11/10/2025 11:17:46 AM] [Error] Error Finalizing Package: Process MakeAppx.exe failed with exit code 1. The values in the registry placed by the application that were captured: And the produced AppXManifest file contained: <com:TypeLib Id="744838d2-7537-47e2-affa-6e0d5fbb61c9"> <com:Version VersionNumber="1.0" LocaleId="0" LibraryFlag="#0"> <com:Win32Path Path="VFS\ProgramFilesX64\Altova\SharedBetweenVersions\AltovaScc32to64Bridge.exe" /> </com:Version> </com:TypeLib> As a workaround, it is possible to manually remove the '#' character from the LibraryFlag field in the AppXManifest allows the package to save. The MMPT should properly read this value as if it were a REG_DWORD of value 0 and generate a valid AppXmanifest. This is a common registry interpretation to make. Alternatively, as the value of 0 is meaningless, the parameter could be dropped, but if the vendor had requested "#1" this should also be handled.Re: Msix packaging tool update
Things have gotten much better with the right tools. See MSIX Report Card for 2025 on how we are doing on that front in repackaging vendor MSIs and Exes into MSIX. And for devs, new development using the .Net 8+ stuff is pretty good as it is built to run in the MSIX container already. But in helping devs with older apps move to the new installer, Microsoft has not provided the help devs need to adapt to the new runtime. I can usually repackage their installers to work, but they don't know how to build one in VS/Code. I have hope that Microsoft has heard this message and will take some new action to help going forward, but we need to see the effort. TimRe: Signtool cannot sign msix file produced by dotnet publish
Additional thought (for anyone running into a signing issue in general, but not necessarily the issue reported here) Please note that he signtool command requires elevation. In the example above, the Q: drive must be available after elevation for this to succeed. Sometimes we copy the package locally, then sign and copy back as a work-around.Re: Msix packaging tool update
While I cannot speak for Microsoft, here is what I think... Microsoft has interest in improving their packaging tool. But I don't believe they seek to make it the best tool out there. There are third party tools today, that either augment or replace this tool, and these allow you to create pretty good MSIX packages. I think Microsoft is happy with this situation. From my conversations with Microsoft, I do believe that they are interested in hearing about specific things you need in that tool that you cannot get elsewhere. You should both raise such items here AND provide feedback through your TAM if you want action.Re: Add Environment Variable to MSIX package using PSF Fixups in Packaging Tool - what am I missing?
Hanessa Ahah! As the dll is present in the root, this procmon error usually indicates missing dependencies of the PSF component. MfrFixup, RegLegFixup, and EnvVarFixup all have documented dependencies. If you are manually adding PSF dlls, most likely you are missing the dependent VC Runtimes. Tooling generally adds these to the VFS\SystemX86 and VFS\SystemX64 folders, so I can't see if they are present. Alternatively, and this is usually preferred, the VC Runtimes are supplied to the end-systems externally - meaning the latest Microsoft VC Runtimes 2015-2022 redistributables Latest supported Visual C++ Redistributable downloads | Microsoft Learn. In that case install both the 32 and 64 bit versions on end-user systems.Re: Add Environment Variable to MSIX package using PSF Fixups in Packaging Tool - what am I missing?
Hanessa If you are adding the PSF using the MMPT, that version of the PSF does not support the EnvVar Fixup. If you added the PSF using PsfTooling (or TMEditX or any of the other third party tool that pulls from the TimMangan fork of the PSF), then the EnvVarFixup is available. However, note that the environment variable will only available to the running applications inside the container - you will not see the variable on the end-user system by looking at environment variables from outside the container.Re: Add Environment Variable to MSIX package using PSF Fixups in Packaging Tool - what am I missing?
Your syntax looks OK to me. I will mention that you will not see the environment variable by using any tools running outside of the container. Also, with userregistry = false you would also not see it in a process run inside the container if that process was not launched by PsfLauncher, which would be any process other than randomapp.Re: How to run edge inside MSIX
Berg745 Additional data on this. I have determined that an app that launches edge from within an MSIX container can indeed run inside the container, even if Edge was already open externally on Win11 24H2. There may be specifics of how this app (which itself knew nothing of being in a container) opened edge, and I will mention that I was using my version of the PSF ( although I am not sure that mattered). A new tab was opened in the existing Edge window, but as each tab is a separate process and that Edge process was running inside the app container. One possible thing you should check is whether you have a setting/policy on edge that affects this in your environment. My edge was set to defaults.Re: Reset user choice for windows.protocol tel:
Interesting issue... Microsoft would certainly be opposed to a package that attempted to take over a protocol handler (or file type association) as they insist that it should be up to the end-user. But that isn't what you are trying to do. Unfortunately, we no longer get much in the way of responses from Microsoft in this tech community, so you only get unofficial thoughts from a "random internet guy". You might need to implement a first run that just prompts the user with information on what they should do to clear it (or better yet instructions on using the Windows Settings app to change it to your handler). There may be ways to have a first run pop out of the container to make the change you wanted, but you would run the risk of rejection by the store submission. Tagging another random person, Bogdan Mitrache , in case he has experience in this area.Re: Why is it impossible to sign a .exe that is included in an msix?
Yes - it is wise to sign the executables that are inside the MSIX also. This is needed for more security conscious customers using things like WDAG, AppLocker, and other software execution protection schemes. Bogdan's approach is correct for projects that allow this. For others that don't (or only allow authenticode signing), you would use a post build script to perform the exe signing. And then use the build project for MSIX and get the package signed also.Re: I'm not seeing what I expected to see with Windows Application Packaging
I believe the "MyAppInstaller" project is an unpackaged form, used for when you want to debug the software in Visual Studio. The "MyAppInstaller (Package)" is for generating the MSIX Package. I have found that it is a tad easier to start a .Net 8/9 single app project by using the template "WinUI Blank App (Packaged with Windows Application Packaging Project" up front, rather than creating the project and then adding the WAP project. With the former, VS does not expose a second project for the packaging, and you just use the "Package menu: Publish/Create App Packages" for the package build. You can also debug the main project in VS this way.Re: Issues Editing MSIX Package to Disable LaunchWhenReady
I don't believe that you can remove the checkbox or affect the default setting, only change the location on the dialog. ...but I understand why you want to... We also allow the use of this customization, we call "branding" in TMEditX (as we don't use the update mechanisms, but I suppose it could be added by editing the xml file after it is added). We don't offer it in PsfTooling.Re: How to run edge inside MSIX
Berg745 Additional thought on this. I found something indicating that Shared Package Container is not supported by Microsoft for Edge. But there is a way (possibly) to achieve what you want by adjusting how your application runs in it's container. In your AppXManifest file, for the application that you are running, add the following as child elements of the application. Check documentation on those elements. There may be capabilities that need be added. Also make sure you add the reference for uap10 in the Package element. I have not tested this myself. <Applications> <Application ... EntryPoint="some.exe" uap10:TrustLevel="appContainer" uap10:RuntimeBehavior="packagedClassicApp"> </Application> </Applications>Re: How to run edge inside MSIX
Bogdan Mitrache On vacation currently so not diving into this right now. But I recall that there is something in the schemas about giving identity to a native app. Maybe it was called external content or something like that. As I recall it, you could add a package that provides the identity for the unpackaged app - which sounds like what you describe. In that case, a packaged app wanting to reference the component would add it as external content in the packaged app AppXManifest. But I thought that was for things other than the exe. The documentation wasn't really clear on the schema (what a surprise!) so this sounds like an area for more detailed testing. There may have been a link to a Microsoft Learning article.Re: How to run edge inside MSIX
Edge also runs in a container, but in that scenario is in a separate container. If it needs to see files in the package, you should try shared package container (Win11 minimum requirement). You'll have to read up on that, but basically you are creating a separate xml file for the package definitions, and use a separate PowerShell command to deploy and activate the xml file. When your app starts, edge should then start in your container.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.
