How does "com4:ManagedInProcessServer" work under a MSIX packaging scenario?
I'm trying to create a MSIX package for a classic Windows desktop app. The app is written in C# (.NET Framework 4.7.2), and it's running perfectly both before and after packaging. The problem is that the app exposes a COM class library (also written in C#) for interop with other apps. The original installer of this app registers the COM library with "regasm.exe". Given that MSIX have the ability to expose COM servers, namely with the "windows.comServer" extension, I've tried adding the following extension to package manifest, but it does not work as intended: <com:Extension Category="windows.comServer"> <com:ComServer> <com:SurrogateServer DisplayName="TheApp Class Library"> <com:Class Id="8ae249dd-05f8-403e-ac32-00feab49c1f5" Path="TheApp.Library.dll" ThreadingModel="STA" /> </com:SurrogateServer> </com:ComServer> </com:Extension> After some research I've found that C# COM libraries registers differently with normal ones; namely it requires a few more entries than DLL path and CLSID written into the registry. Digging through the documents, I've found that https://learn.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-com4-managedinprocessserver seems to be just what I needed. So I've tried to use the following extension instead: <com4:Extension Category="windows.comServer"> <com4:ComServer> <com4:ManagedInProcessServer Assembly="TheApp.Library, Version=1.0.0.0, Culture=neutral" RuntimeVersion="v4.0.30319"> <com4:Class Id="8ae249dd-05f8-403e-ac32-00feab49c1f5" ImplementationClass="TheApp.Library.ExtensionManager" ThreadingModel="STA" Virtualization="disabled" /> </com4:ManagedInProcessServer> </com4:ComServer> </com4:Extension> But it still does not work. In fact, this time even the "HKEY_CLASSES_ROOT\CLSID\{...}" registry entries do not get generated. I've checked the https://learn.microsoft.com/en-us/windows/win32/appxpkg/troubleshooting#get-diagnostic-information and no error has ever occurred during package installation. It is as if the extension declaration is not there. What confuses me more is that "com4:ManagedInProcessServer" does not allow specifying codebase for the assembly. With "regasm.exe" one can specify the full path to COM library with "/codebase", but "com4:ManagedInProcessServer" does not seem to be allowing this. I've been looking for relevant information for quite some time, but all I could find is the single document page on XML schema (linked above), with no real-world code examples. (And by "no" I mean literally ZERO code example on Internet.) I would like to know if "com4:ManagedInProcessServer" works under the situation described above, and if not so, what should I do to have a C# COM library exposed by a MSIX package? If it matters, I'm using the latest version of Visual Studio Community 2022 with SDK version 10.0.22621.0. The MSIX package is to be deployed on a Windows 11 23H2 system.Desktop Bridge – The bridge between desktop apps and the Universal Windows Platform
First published on MSDN on Oct 13, 2016 A couple of years ago, during the BUILD conference, Microsoft announced a technology called Project Centennial, which goal is to help developers to take their existing traditional desktop applications and to bring them to the Store, along with the native full Universal Windows Platform apps.
FileSystemWatcher not working in Desktop Bridge app
Hello, I have a problem with FileSystemWatcher within a desktop bridge app. I asked for this issue already in the WPF forum in Microsoft answers, but from there I was referred to this forum here. I have a WPF app that uses FileSystemWatcher for various directories to react to changes in the directories. For example: "C:\ProgramData\Microsoft\Windows\Start Menu" "C:\Users\Egon\AppData\Roaming\Microsoft\Windows\Start Menu" As long as I start the app directly as a WPF desktop app, I get all the events when there is a change in both directories. However, if I add a package project to the solution and launch the app as a desktop bridge app via the package project, I only get events for the general Start Menu directory, but no more events for the Start Menu directory for the user. This is reproducible on Windows 10 (VS2017) and Windows 11 (VS2022) both with .NETFramework 4.8. I have tested Win32 API versions for directory monitoring within a WPF app as normal desktop app and as desktop bridge app: ReadDirectoryChangesW() without OVERLAPPED ReadDirectoryChangesW() with OVERLAPPED and GetOverlappedResult() FindFirstChangeNotificationW() with WaitForSingleObject() In none of these variants do I get a signaled event. As a normal desktop app they all work fine, but as a desktop bridge app they keep hanging when I monitor the user's start menu directory. https://1drv.ms/u/s!AnJkahC5qjfigQtE11JnXUStrK_e?e=adLu2E, I have a zip file with the source code. Ensure, that the project 'PackageDirectoryWatcher2' is set as start project. Start this sample, then copy any file into directory C:\Users<YourName>\AppData\Roaming\Microsoft\Windows\Start Menu\ or its sub directories. In the app window you will see, that nothing happens, means that the FileSystemWatcher doesn't invoke an event. Then close the app, set the project 'DirectoryWatcher2' as start project and start the app again. Now, if you copy any file into directory C:\Users<YourName>\AppData\Roaming\Microsoft\Windows\Start Menu\ the app window shows the triggered events. So this is the difference between 'normal desktop' and 'desktop bridge' in the app behavior. Is there any way to get notified within a desktop bridge app about changes in the user's start menu directory?Porting and testing your classic desktop applications on Windows 10 S with the Desktop Bridge
First published on MSDN on Jun 15, 2017 On 2nd May Microsoft has announced Windows 10 S, a new Windows 10 edition (based on the same Creators Update version, which means build 15063) designed specifically for scenarios where the customer wants to put safety and security first above all when they use their devices.Unpackage, modify, repackage, sign an APPX
First published on MSDN on Aug 07, 2017 If you are working on a desktop application that you want to release on the Windows Store by packaging it with the Desktop Bridge, you’ll know that one of the requirements is that your application should work fine also on Windows 10 S, the new Windows edition that was introduced on 2nd May 2017.Using the Desktop App Converter tool on an updated Windows version
First published on MSDN on Nov 22, 2017 Being able to distribute your classic Desktop App through the Windows Store is a great opportunity to target the 500M+ Windows 10 active users!So you may be using the Desktop App Converter tool and you might have the following error since an major Windows Update:'E_NO_EXPANDED_BASE_IMAGE': No expanded base Images were found a 'C:\ProgramData\Microsoft\Windows\Images'.
