Private SxS Components (registration-free COM)

Question

My application has private SxS components that it includes with an Application Manifest. This manifest includes dependentAssembly nodes that refer to COM DLLs in the same folder that have embedded assembly manifests. This all works fine outside of MSIX, but fails with a standard SxS error when packaged (The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail).

Looking at the goings-on in Procmon, I can see that it's the 'csrss.exe' Windows component that is performing the lookup for the dependencies, and since this lives outside the container and is not invoked by my app directly (it's always running in the background), it is looking in the real ProgramFilesX86 folder rather than the one in the VFS that actually contains the DLLs.

Does anyone have any suggestions on what the best way to handle this would be? I've tried the PSF FileRedirectionFixup and DynamicLibraryFixup in PSF, which don't work - I suspect this is because csrss isn't something that is being created from my application, but rather is something running in Windows and handling SxS, and so it isn't being intercepted. The bitness doesn't always match either, so I don't think PSF could intercept it even if it wanted to (my app is x86 due to 3rd part native components, but csrss is x64 on an x64 system).

My only fallback is to munge the VREG such that the components are registered 'globally' rather than privately (which is fine for MSIX as it's scoped to the container), but that means I need to have different Application Manifest files depending on if I'm packaging MSI versus MSIX (I ship both) since the exe will be expecting SxS as-is.

timothy_mangan · Answer

I can confirm that applications with private manifests under MSIX seem to fall victim to the error message you mention (but not always). There is nothing in the PSF to help with this issue today, even after devoting a lot of time fruitlessly debugging these situations.

My normal procmon trace excludes the csrss process, so I hadn't noticed it's involvement. Perhaps that will prove important.

jdhintercede · Answer

If it helps, this is only an issue for my .NET COM components as the SxS stuff is pretty strict about the presence of assemblyIdentity in the manifest; the native components are perfectly happy being registered directly in the application manifest rather than via dependentAssembly with embedded assembly manifests, whereas the .NET stuff requires a manifest per component since it requires assemblyIdentity, which can only appear once in a manifest.

I guess I will have to just update the CI pipeline to use different manifests for MSI versus MSIX, and register the offending components in the VREG for the latter (I've quickly proven this out by hand and it works fine for my case). Not ideal, but it works.

timothy_mangan · Answer

JDHIntercede&nbsp;Sounds like the right approach.
&nbsp;
I'm running into this in trying to repackage existing MSIs into MSIX.&nbsp; Can you describe how to tell if the manifest is for registration-free COM?&nbsp; A sample manifest would go a long way to help me understand this.

jdhintercede · Answer

TIMOTHY_MANGAN&nbsp;It pretty-much comes down to the elements inside it.You can extract a manifest using mt.exe (https://docs.microsoft.com/en-us/windows/win32/sbscs/mt-exe) with the following:&nbsp;mt.exe -inputresource:TheApplication.exe;#1 -out:extracted.manifest&nbsp;&nbsp;If you open up the file you extracted, you're looking for elements like &lt;comClass&gt;, &lt;typelib&gt;, &lt;comInterfaceExternalProxyStub&gt; (docs https://docs.microsoft.com/en-us/windows/win32/sbscs/application-manifests&nbsp;schema is https://docs.microsoft.com/en-us/windows/win32/sbscs/manifest-file-schema).&nbsp;&nbsp;I've found that registrations directly inside the application manifest (i.e. the manifest in the application executable) seem to work fine. The issue comes about when the manifest is referencing external manifests, even if these are private and in the same folder. To identify this kind of thing, look for something like:&nbsp;	&lt;dependency&gt;
		&lt;dependentAssembly&gt;
			&lt;assemblyIdentity name="SomeComponent" version="1.2.3.4" publicKeyToken="00000a0000cb0d0c" processorArchitecture="x86"/&gt;
		&lt;/dependentAssembly&gt;
	&lt;/dependency&gt;&nbsp;&nbsp;These entries are saying I depend on 'SomeComponent' with the identity specified, and the loader will look first in the GAC, then in the current directory for a DLL/manifest with the same name (this is the bit that's not respecting the VFS in MSIX), then, if not found, in a subdirectory with the same name. Side note: regardless of MSIX, if it finds a DLL with the same name, but without an embedded manifest, before it finds a standalone manifest file, it will fail - this can cause problems where the manifest file is standalone rather than embedded, as the loader stops looking after the failure even if the manifest exists.

timothy_mangan · Answer

JDHIntercede&nbsp;Yeah, I've been digging into this a little.
&nbsp;
I am fairly sure that you should be able to use the components with either internal or external application and component manifests in your MSIX package AS IS.&nbsp;
&nbsp;
The trick will be to add the com registration directly into the AppXManifest.&nbsp; This, in essence, it the modern way to advertise the com components, whether or not they originally were registration-free or registered in the registry.&nbsp; It allows for side-by-side deployment in the package, but the installation of the MSIX package writes the registration from the AppXManifest into a new per-package location in the registry to make things easy to clean up.
&nbsp;

Forum Discussion

Private SxS Components (registration-free COM)

8 Replies

Resources