User Profile
TIMOTHY_MANGAN
MVP
Joined 8 years ago
User Widgets
Recent Discussions
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. Tim6Views0likes0CommentsRe: 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.5Views0likes0CommentsRe: 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.17Views0likes2CommentsRe: 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.5Views0likes0CommentsRe: 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.5Views0likes0CommentsRe: 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.85Views1like2CommentsRe: 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.19Views0likes0CommentsRe: 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.71Views1like1CommentRe: 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.30Views1like0CommentsRe: 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.30Views0likes0CommentsRe: 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.57Views0likes0CommentsRe: 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>66Views0likes2CommentsRe: 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.68Views0likes1CommentRe: 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.120Views0likes4CommentsRe: Cannot install or update UWP or WinUI apps using msixbundler
Microsoft disabled AppInstaller as an external file by default a while back. The AppInstaller file may be included directly in the package instead. There is a group policy to enable external AppInstaller files. I don't know if the disablement was specific to domain join or not, but perhaps that is the case.54Views0likes0CommentsRemoval 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.91Views0likes0CommentsRe: Encountered 0x80131500 code while using MSIX Packaging Tool
Well one thing I notice is the Identity Name value in the AppXManifest. The minus character is not allowed in that field. The GUI of the tool would not have allowed it, so my guess is that you manually changed it in the AppXManifest. To me the strange thing is that I expect the tool to generate a specific error for that. Certainly the EventLog Microsoft\Windows\AppXOperational should have an error that points to the exact line and field of such an issue.54Views0likes0Comments.WapProj build using "unvirtualizedResources" removed entry from manifest
I have a .wapproj that needs to use RegistryWriteVirtualization (aka "Flexible Virtualization) as described in Flexible virtualization - MSIX | Microsoft Learn This is for an MSIX package that will not be delivered via the Microsoft Store. The changes are made to the Package.appxmanifest file, and saved. The build action in Visual Studio removed the Capability declaration line for "unvirtualizedResources" from the Package.appxmaifest file before processing the file, leading to an error complaining that the RegistryWriteVirtualization requires this capability. Workaround: I can mark the file read-only outside of Visual Studio to keep VS from changing the file as a temporary workaround to prove out that the code depending upon these settings works. Why workaround is not acceptable: This workaround is not long-term viable, as other developers and automated workflows working on the project will lose the read-only setting (as it will not persist in GitHub) and have a broken build. It is clear that the VS code looking at this file is aware of both the desktop6 and virtualization schemas and their requirements and restrictions, but seemingly, although aware of other rescap capability extensions is unaware of this one. Requested action: Please add support for missing capabilities declarations in Visual Studio and/or underlying tools.156Views1like2Comments
Recent Blog Articles
No content to show