Does the COM call COM, which in turn calls another. COM COM object works when using SxS, and manifest files are used

Question

I have a .net application application for a COM component (C ++), which, in turn, calls another COM object implemented in .NET.

This application uses the capabilities of Windows SxS and does not register any of its COM components. Not the one written in C ++, but not the one written in .net.

This first call to the C ++ COM component works fine. But when the C ++ COM component calls .net, it fails with the unregistered class.

I tried to create a little C ++ application with a manifest file that calls the .net component and it works. It seems that with the stream .net -> COM NATIVE -> .NET COM. Then SxS breaks and does not work.

When viewing Fusion logs (build build logs), I see that no one is even trying to allow .NET COM builds.

Is this SxS script supposed to work (I think it should work)? If so, what can I do wrong?

These are the manifest files that I use.

application manifest for .net application (embedded as a resource):

<?xml version="1.0" encoding="utf-8"?> <asmv1:assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv1="urn:schemas-microsoft-com:asm.v1" xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <assemblyIdentity version="1.0.0.0" name="MyApplication.app"/> <file name="DotNetComConsumer.dll" hashalg="SHA1"> <comClass clsid="{44E69FC9-5EAF-4D57-8C09-430F703AD82F}" tlbid="{4F81C9C3-FDDF-48F6-BC25-6F8CD458EBE6}"/> <typelib tlbid="{4F81C9C3-FDDF-48F6-BC25-6F8CD458EBE6}" resourceid="1" version="2.0" helpdir="" flags="HASDISKIMAGE"/> </file> <comInterfaceExternalProxyStub name="_Class1" iid="{5D41351A-440B-4175-9296-72D5EED83AA7}" tlbid="{4F81C9C3-FDDF-48F6-BC25-6F8CD458EBE6}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}"/> <dependency> <dependentAssembly> <assemblyIdentity type="win32" name="application.sxs" version="1.0.0.0" /> </dependentAssembly> </dependency> </asmv1:assembly> 

application.sxs.manifest (regular file):

 <?xml version="1.0" encoding="utf-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <assemblyIdentity type="win32" name="application.sxs" version="1.0.0.0"/> <dependency> <dependentAssembly> <assemblyIdentity name="PerformanceMonitor" version="10.0.0.9999" publicKeyToken="792843134cf0407a" processorArchitecture="msil"/> </dependentAssembly> </dependency> </assembly> 

PerformanceMonitor metric (implemented as a resource in PerformanceMonitor.dll for dealing with .net com error in XP):

 <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <assemblyIdentity name="PerformanceMonitor" version="10.0.0.9999" publicKeyToken="792843134cf0407a" processorArchitecture="msil"></assemblyIdentity> <clrClass clsid="{AA614438-BC7D-400c-8837-525BFBB7253A}" progid="PerformanceMonitorFactory" threadingModel="Both" name="PerformanceMonitorFactory" runtimeVersion="v2.0.50727"></clrClass> <file name="PerformanceMonitor.dll" hashalg="SHA1"/> </assembly> 

Answer 1

It works, but there are things that can break it (as I found out).

Apparently, if your application is a WinForms application and uses the Application.EnableVisualStyles command to use the visual styles provided by the OS, and at the same time uses manifest files to create an activation context, then you are in a pickle.

It seems (according to this ) that this command itself creates an activation context to redirect the process to use Microsoft.Windows.Common-Controls version 6.0.0.0. And for some reason this violates the use of the .net com object that you define in the manifest file.

Removing Application.EnableVisualStyles from the application and replacing it with this dependency in the manifest file seems to do the trick:

 <dependency> <dependentAssembly> <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="X86" publicKeyToken="6595b64144ccf1df" language="*" /> </dependentAssembly> </dependency>