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.
blocking : Weird cursor behavior + slow down, when any picture in header/footer
note : Same issue has been reported a few days ago but was closed without real solution. Affected versions : All Office version since 16.0.18925.20138 (tested 16.0.18925.20138, 16.0.18925.20158, 16.0.18925.20168, 16.0.18925.20184), 32 bits and 64 bits. Last good version : 16.0.18827.20176 Observed behavior : When any picture is present in header or footer, with a moderate size document, cursor can go blinking between normal and busy. This is slowing down typing. To reproduce, create a blank document, insert a picture in header or footer, add 30 pages of text, scroll down until the cursor become crazy. Some technical notes : The document window _Wwg is receiving a constant stream of WM_NCHITTEST even without mouse moving. This does not happen in draft mode. Hiding space between pages does not resolve the issue removing the picture in header/footer resolve the issue picture format does not seem the source of the issue : tested various bmp, jpg, bmp, wmf the behavior can be reproduced in safe mode (no addins) rolling back to version 16.0.18827.20176 via ODT tool solve the issue. Last version of "Microsoft Office Group Policy and Office Customization Tool Settings" is from before those bad updates, we have not yet found an option or setting somewhere that could resolve the issue. The problem is widespreading to our customers (1000s) who produce legal documents, only solution so far is to rollback office or teach them to work in draft mode to mitigate the issue. Since this also happens in safe mode we cannot circumvent the problem. If anyone has found a source for this problem please comment, maybe we can find a solution in waiting for a fix. Another issue since 16.0.18925.20138, only on 64 bits : After a programmatic SaveAs, or ExportAsFixedFormat (PDF), COM reference of document become invalid. This can be circumvented by updating hold references to the document object. Some windows are recreated also.
