Support for loading .NET DLLs with embedded manifests declaring clrClass GUIDs

Daniel Kamil Kozar dkk089 at gmail.com
Sat Jul 21 16:38:40 CDT 2018


Hello, Wine developers.
I've been independently trying to get to the bottom of bug 43270,
which is the last bug keeping the application from achieving the same
functionality as on Windows.
>From what I've been able to find out, a .NET DLL which contains an
embedded manifest and the implementation of an internal plugin
interface fails to load, which leads to the functionality not being
available at program runtime.
The request to create an instance of the class provided by said DLL is
done by calling CoCreateInstance() from another DLL, which contains a
"startup helper" and is called by the application in an early stage.
CoCreateInstance() correctly calls into mscoree in order to service
the request for creating the instance, but the function takes a peek
into the registry for the CLSID information for some reason.
I'd like to know, if possible :
1. Is CoCreateInstance() supposed to look into the registry for
information regarding "registration-free" (i.e. with an embedded
manifest) .NET DLLs? I haven't found the CLSID inside the registry in
a working real Windows installation, so it doesn't seem likely to me.
2. How are the "registration-free" DLLs supposed to be located? The
only thing I could find regarding this is the add_dll_redirect()
function in actctx.c, which is called when the manifest contains a
<File> directive. However, adding the directive to said DLL's doesn't
help, as the file still fails to load, despite the same code path
being executed and the DLL being added to the redirects.
3. Generally, is a similar setup currently supported by Wine? Or am I
just looking for stuff that simply doesn't exist inside the source?

Thank you in advance,
Daniel



More information about the wine-devel mailing list