Forum Widgets
Latest Discussions
AppCompat with MSIX
Hi, I'm repackaging some (very) old apps in MSIX, and I'm facing a situation where I need to enable some app compatibility shims. I've tried doing this with the `registry.dat` registry hive, but it doesn't seem to work. I think I've heard something about using SDB in a MSIX package once, but I might be imagining things. Right now I've resorted to using an ImportRedirectionTable and a redirection DLL, but this only works for simple cases like Windows version lie. It would be amazing if there was a way to use an SDB inside a MSIX, but if the registry option could work, that'll do too. Did anybody manage to make this work? Thanks!
MSIX product name issue
Hello, Please advise when creating Msix packages, how can I set different product names to be shown in the: Start Menu > Applications < My Product > vs Settings > Apps < My Product Pro > Generally, in which fields these 2 names are set? Thanks for the info, highly appreciated :)Unable to build APPXUPLOAD from .NET 9.0 / C# / WinForms project
Hi! We were advised by Microsoft Visual studio Developer community to create this issue on GitHub. But it was wrong direction. So, you're the third instance where we're trying to solve it. We hope that it is relevant to this section. Please, let us know if not. The corresponding threads can be found here and here. --- The essence We’ve met this problem during the project (C#, WinForm) migration from .NET Framework 4.8.1 to .NET 9.0. Steps to see the problem We’ve migrated the project, compiled it and tested its functionality. Here we’ve found out that we are now required to publish the app with the .pubxml profile to make a single and not self-contained .exe instead of .exe-.dll-.json-.json… whatever this supposed to be. Using the publishing profile we’ve obtained the single-file executable that we’ve tested on Win10-x64 and Win7-x86. Both tests have been passed. The installation of .NET 9.0.4 desktop redistributables is not the problem for our aims. It is even better to not to “take” it with the executable. We’ve removed the .NET Framework project and added the .NET 9.0 project to the .wapproj dependencies without other changes. After this we get 3 warnings (fig. 1) about compatibility. After that we can get two results: The builder can create a 100Mb bundle for 450Kb executable or (if single file option is enabled) 100Mb the-entire-OS-in-one-file executable. So, we literally can build package. But it will completely ruin the user (who downloads the app from Microsoft Store) experience. Not to mention that such an installation size is simply inadequate for the goals and objectives of the product. With another project (we've tried it too) the builder can refuse to build the code during to non-existing errors (like missing ‘using’ directive). Exactly the same code has been successfully built during the publishing process 10 seconds ago. Our thoughts: there is some problem in the .wapproj file and/or in the MSIX builder. Because all warnings and errors come from the step before zipping .MSIXs into .appxbundle. --- How to reproduce directly Use this project to build a single-file-exe: TestProject_NET9.zip. This is the partial copy of our actual product without our own sensitive assemblies. It’s free for testing (available on GitHub). Add the new MSIX/APPX packaging project, connect the .NET 9.0 project to it. We can only provide our sample of .wapproj, without certificates and thumbprints, just to check its properties and verify its integrity: ScreenShooter_MSIX.zip. Try to publish the bundle. Tried workarounds Creating new .wapproj: no effect Clearing all building directories and caches: no effect Updating NuGets: no effect Other notes Also when builder tries to do its work we can see about 900 warnings about possible compatibility problems for basic methods from System, System.Windows.Forms and other assemblies. So, now we can still publish Android apps, APKs, Windows MSI packages, EXEs. But we cannot build apps for Microsoft Store. Which is not funny at all. --- So, how can we fix it? We’ve lost 6 hours in search. But found nothing useful. Thank you in advance, RD AAOW FDLRunning 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.
MSIX Packaging Tool Command Line?
Has anyone succesfully used the MSIX Packaging Tool Command Line functionality? I haven't had any luck getting the packaging process to work with a template, and I can't find a single tutorial or post on the internet addressing it (besides the MS docs, which don't have any troubleshooting help). I see the create-package command has a verbose option, but I don't understand the error. Is there maybe event logs with additional info? Here's the verbose logging of my error: Running the installer About to start process - File name: %UserProfile%\Downloads\App\App Client Setup.exe - Arguments: /S /v/qn Received code 6 for job 2060 with value 13240 Installer still running Received code 7 for job 2060 with value 13240 Installer still running Received code 4 for job 2060 with value 0 App Client Setup.exe failed, exit code = -858993460 Restoring the environment Starting service. ServiceName : WSearch. Enabled Service : WSearch The conversion operation failed with: Process App Client Setup.exe failed with exit code -858993460. Stopping monitoring session Stopping the Monitoring session Stopping reboot listener Not really sure where to start with debugging this! I proved that I was able to run the installer directly from CMD using these same arguments and it installs fine.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 Thanks
Signtool 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”PackageDependencies 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.
