Forum Widgets
Latest Discussions
User settings and perferences with App Attach
Hi everyone, I'm currently working in a test environment where I have several msix app attaches. Everything works fine, except the User settings. For example the dark mode setting in adobe dc reader, is not saved after ending the user's session in azure. So after you end the session completely it is like a freshly installed app without any settings saved. The same thing happens for SAP and other applications. The User settings are saved, if I install the app locally on my computer. Is there a way to fix this? Many ThanksNZ463Apr 09, 2025Copper Contributor343Views0likes3CommentsSigntool cannot sign msix file produced by dotnet publish
Used dotnet publish to generate a msix package (from Blazor MAUI project). During the process, dotnet has signed the msix file using our EV certificate, but it did not time-stamp it. So we’ve decided to re-sign it using signtool from Win SDK latest version 10.0.22621.0. However, the signtool reports an error: SignTool Error: This file format cannot be signed because it is not recognized. Using the same options to sign a regular msi file (from another project) produces no error. Here is the complete command line used to sign both msix and msi (with the /sha1 thumbprint truncated for privacy): “C:\Program Files (x86)\Windows Kits\10\bin\10.0.22621.0\x64\signtool.exe” sign /a /sha1 e392… /tr http://timestamp.digicert.com /fd sha256 /td sha256 /d “test” /du http://www.winability.com “Q:\test-x64.msix”AndreiBelApr 07, 2025Copper Contributor1.7KViews0likes6CommentsRunning windows service that's a part of a Desktop Bridge WFP app blocks update
I have a WPF application that has been packaged using DesktopBridge into MSIX and submitted to the Microsoft Store. This application has a WPF UI component, and it also has a windows service component that runs in the background whenever the PC is turned on. The UI component is used for configuring user settings and credentials for the windows service, and the windows service is actually the main component of this app. It's designed this way because of our client's needs. The problem that I'm running into is that when we publish a newer version to the Microsoft Store, the app fails to update with an error "0x80073D02: The package could not be installed because resources it modifies are currently in use" It looks like this is caused by the running windows service, and the store app update is not able to stop the service before the update replaces the files in the VFS. When the user manually stops the windows service, the update completes just fine and restarts the windows service as expected. When testing the update using different versions of MSIX files, I noticed that appending the flag -ForceApplicationShutdown to the Add-AppPackage command will achieve what I need, but this doesn't seem to be an option in the windows application packaging project, or in the Microsoft Store submission process. I know that including a windows service within an MSIX package is a restricted capability, so is this behavior due to the usage of this restricted capability? Also, is there a fix or workaround that will allow the update process to automatically stop the windows service before trying to replace the files? Thank you for any help or suggestions, and I'm happy to provide any additional information needed.mgong_entegralApr 07, 2025Copper Contributor56Views0likes0CommentsPackageDependencies and RtlDosApplyFileIsolationRedirection
For security purposes, we would prefer to keep all of the VCRuntime dlls out of MSIX packages and instead replace them with Microsoft.VCLibs.xxx package dependencies. For most applications (being repackaged), we can simply remove the files from the package and add the dependency in the AppXManifest file. LoadLibrary happily finds the files in the dependency package without need of the PSF. There are applications, however, that have folders containing numerous managed dlls along with the VCRuntimes in a folder, and use an internal manifest in the exe that includes a Dependency / dependentassembly / Assemblyidentity that lists the folder, and then an external manifest in that folder that lists all of the dependent dlls to be loaded. When the application process is launched, the internal manifest is processed and we see the dlls listed in the external manifest being located using the API RtlDosApplyFileIsolationRedirection rather than load library. It appears that this API does not look at the location containing AppXManifest PackageDependencies thus the dlls are not found and the launch of the exe fails. The PackageDependencies should always be respected or they are useless. I have an example package (Blender) that has this condition if you'd like to look at it.332Views0likes2CommentsPreview Handler with MSIX Packaging Tool?
Can anyone point me to a full example of an MSIX manifest file with a working preview handler for a custom file extension? I have developed a Windows exe and a dll preview handler for a custom file extension. I have a working Inno Setup installer that creates file associations for the file extension and assigns a preview handler so that the files can be previewed in Windows Explorer. I'm then using MSIX Packaging Tool to create an MSIX from the Inno exe installer. It mostly works and file associations are created correctly for the custom file extension. However, the preview handler doesn't work. Windows Explorer just shows 'Preview Unavailable' in the preview pane. I have found this topic, but it seems unresolved. Was this issue ever solved? Preview Handler in MSIX | Microsoft Community Hub From this I have found that entries may be missing from my manifest file for desktop2:DesktopPreviewHandler and com:SurrogateServer. However, I am new to MSIX and my efforts to add them in based on the documentation (link below) only results in an 'Unable to parse manifest' error from the MSIX Packaging Tool. The log file isn't much help showing only '[Error] System.Runtime.InteropServices.COMException'. https://learn.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-desktop2-desktoppreviewhandler Can anyone point me to a working example for a manifest file for a preview handler for a custom file extension, or a good tutorial? Here's my manifest file (with specifics renamed). <?xml version="1.0" encoding="utf-8"?> <Package xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10" xmlns:uap="http://schemas.microsoft.com/appx/manifest/uap/windows10" xmlns:uap2="http://schemas.microsoft.com/appx/manifest/uap/windows10/2" xmlns:uap3="http://schemas.microsoft.com/appx/manifest/uap/windows10/3" xmlns:uap10="http://schemas.microsoft.com/appx/manifest/uap/windows10/10" xmlns:desktop2="http://schemas.microsoft.com/appx/manifest/desktop/windows10/2" xmlns:desktop7="http://schemas.microsoft.com/appx/manifest/desktop/windows10/7" xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities" IgnorableNamespaces="uap uap2 uap3 uap10 desktop7 rescap"> <!--Package created by MSIX Packaging Tool version: 1.2024.405.0--> <Identity Name="CompanyName.AppName" Publisher="---------------------------------------" Version="1.1.1.0" ProcessorArchitecture="x86" /> <Properties> <DisplayName>App Name</DisplayName> <PublisherDisplayName>Publisher Name</PublisherDisplayName> <Description>App Name</Description> <Logo>Assets\StoreLogo.png</Logo> <uap10:PackageIntegrity> <uap10:Content Enforcement="on" /> </uap10:PackageIntegrity> </Properties> <Resources> <Resource Language="en-us" /> </Resources> <Dependencies> <TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.17763.0" MaxVersionTested="10.0.22000.1" /> <PackageDependency Name="Microsoft.WindowsAppRuntime.1.4" MinVersion="4000.1010.1349.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" /> </Dependencies> <Applications> <Application Id="EXENAME" Executable="VFS\ProgramFilesX86\App_Name\AppName.exe" EntryPoint="Windows.FullTrustApplication"> <uap:VisualElements BackgroundColor="transparent" DisplayName="App_Name" Square150x150Logo="Assets\APPNAME-Square150x150Logo.png" Square44x44Logo="Assets\APPNAME-Square44x44Logo.png" Description="App Name"> <uap:DefaultTile Wide310x150Logo="Assets\APPNAME-Wide310x150Logo.png" Square310x310Logo="Assets\APPNAME-Square310x310Logo.png" Square71x71Logo="Assets\APPNAME-Square71x71Logo.png" /> </uap:VisualElements> <Extensions> <com:Extension Category="windows.comServer"> <com:ComServer> <com:SurrogateServer> <com:Class AppId="64644512-C345-469F-B5FB-EB351E20129D" SystemSurrogate="PreviewHost" /> </com:SurrogateServer> </com:ComServer> </com:Extension> <desktop7:Extension Category="windows.shortcut"> <desktop7:Shortcut File="[{Common Programs}]\App_Name\App_Name.lnk" Icon="[{Package}]\VFS\ProgramFilesX86\App_Name\AppName.exe" /> </desktop7:Extension> <uap3:Extension Category="windows.fileTypeAssociation"> <uap3:FileTypeAssociation Name="ext"> <uap:SupportedFileTypes> <uap:FileType>.ext</uap:FileType> </uap:SupportedFileTypes> <uap:Logo>Assets\ext.png</uap:Logo> <uap2:SupportedVerbs> <uap3:Verb Id="open" Parameters=""%1"">open</uap3:Verb> </uap2:SupportedVerbs> <desktop2:DesktopPreviewHandler Clsid="64644512-C345-469F-B5FB-EB351E20129D" desktop10:DisplayName="AppNameEXTPreviewHandler" /> </uap3:FileTypeAssociation> </uap3:Extension> </Extensions> </Application> </Applications> <Capabilities> <rescap:Capability Name="runFullTrust" /> </Capabilities> </Package>peterboneApr 02, 2025Copper Contributor92Views0likes2CommentsMEF's CompositionException issue with MSIX
I am developing a C# project relying on Managed Extensibility Framework (MEF) to do its job, with Services .DLL like [Export(typeof(IPerson))] public class People : IPerson { ... } that are Lazily detected in a Factory based on public class MyFactory { [ImportMany] IEnumerable<Lazy<IPerson>> m_Crowd; private CompositionContainer m_Container; ... private void Initialized() { var catalog = new AggregateCatalog(); catalog.Catalogs.Add(new DirectoryCatalog(AppDomain.CurrentDomain.BaseDirectory)); m_Container = new CompositionContainer(catalog); this.m_Container.ComposeParts(this); foreach (Lazy<IPerson> ppl in m_Crowd) { if (ppl != null) { var foo = ppl.Value; ... } } } The Service DLLs are placed on the same folder as the .exe, hence the catalog.Catalogs.Add(new DirectoryCatalog(AppDomain.CurrentDomain.BaseDirectory)); Everything works fine until we decided to wrap the project in a MSIX package ("Windows Application Packaging Project"). Once the package deployed, there is a crashing Runtime error at line var foo = ppl.Value; --> System.ComponentModel.Composition.CompositionException: The composition produced a single composition error. The root cause is provided bellow. Review the CompositionException.Errors property for more details information. 1) Le fichier de la clé n'a pas été trouvé (pardon my french) Resulting in: The type initializer for 'People' threw an exception Resulting in: An exception occurred when trying to create an instance of type 'People' Resulting in: Cannot activate part 'People' Element: People --> People --> AssemblyCatalog (Assembly="People, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null") Resulting in: Cannot get export 'People' (ContractName="IPerson") --> People --> AssemblyCatalog (Assembly="People, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null") at System.ComponentModel.Composition.Hosting.CompositionServices.GetExportedValueFromComposedPart(ImportEngine engine, ComposablePart part, ExportDefinition definition) at System.ComponentModel.Composition.Hosting.CatalogProvider.GetExportedValue(CatalogPart part, ExportDefinition definition) at System.ComponentModel.Composition.Hosting.CatalogProvider.CatalogExport.GetExportedValueCore() ... at System.Lazy`1.CreateValue() ... (I cannot copy/paste from my working environment, this is a manual, obfuscated transcription) TL;DR: the main program could detect the Service DLL ("Assembly="People, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"") but couldn't dynamically load it. I have a feeling comes from the way MSIX packaged are stored, in a weird C:\Program Files\WindowsApp\Project_1.0.0.0_x64_8wekyajsusuh\Project folder where the laws of catalog.Catalogs.Add(new DirectoryCatalog(AppDomain.CurrentDomain.BaseDirectory)); would not correctly work. Thanks in advance for any help of this topic!50Views0likes1CommentMSIX appinstaller - how to include additional files
Hi, I'm new to MSIX. I'm using Visual Studio to build an app installer for a solution consisting of an .EXE project and some .DLL projects. There are some other files and dlls used by the project items, which are not directly referenced in any of the projects in the solution. However, these files are needed for the successful deployment of the application. My question is, how do I get the app installer to include these additional files? Thank you.staffordaMar 19, 2025Copper Contributor118Views0likes1CommentMSIX Packaging of Office applications ( VISIO/PROJECT/PROPLUS)
Hi Everyone , has anyone tried to create MSIX package for office application. I am creating it. after MSIX conversion , when I launch the shortcut it says "the Parameter is incorrect" however there is no parameter passed to target exe ( VISIO.exe)SolvedArchana2612Mar 14, 2025Copper Contributor6.8KViews1like10CommentsFile Redirection crashes on Windows 11 24H2
I have noticed that some applications deployed with MSIX packages and having file redirection fixups can be correctly launched on Windows 11 22H2 or 23H2, but crash on Windows 11 24H2. If Config.json contains a snippet: "fixups": [ { "dll": "FileRedirectionFixup.dll", "config": { "redirectedPaths": { and a MSIX package integrates the latest PSF release (version 1.0.240212.1), applications crashes during initialization, and the Event Viewer contains these errors: Faulting module name: FileRedirectionFixup64.dll, version: 0.0.0.0, time stamp: 0x63f88f2e Exception code: 0xc0000005 Fault offset: 0x0000000000009809 Faulting process id: 0x2688 File redirection seems to work well with previous Windows builds. What is the cause of this error? Why is it observed only on Windows 24H2? Are FileRedirectionFixup64.dll assemblies released with PSF 1.0.240212.1 or earlier PSF versions compatible with Windows 11 24H2? Can PSF vendors and MSIX experts shed light on this problem?Telemak68Mar 11, 2025Copper Contributor121Views1like1Comment
Resources
Tags
- MSIX64 Topics
- appinstaller6 Topics
- msix packaging tool5 Topics
- APPX4 Topics
- MSIX Packaging Tools4 Topics
- MSIX AppAttach launch failure3 Topics
- Access MSIX Container3 Topics
- appattach3 Topics
- MSIX LIMITATIONS3 Topics
- Capabilities2 Topics