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

[Daniel Kamil Kozar]

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

[Nikolay Sivov]

Hi, Daniel.

As far as I remember, from context side for clrClass case we add a 
module name as mscoree.dll, and the rest stays the same as with regular 
classes.

On creation attempt, mscoree.DllGetClassObject is supposed to be called. 
Do you see this happening?
If it gets to this point, try to install .NET framework (that will 
install native mscoree too), and see if that improves things.

[Daniel Kamil Kozar]

Hi, Nikolay.
Thanks for the reply. Unfortunately, I've already tried installing the
.NET framework (i.e. via winetricks dotnet20), and the results are
pretty much the same.
DllGetClassObject does get called, but returns different values
depending on whether dotnet20 is installed or not : without it (i.e.
by using Wine's mscoree.dll) the return value is
CLASS_E_CLASSNOTAVAILABLE (due to the registry lookup in
create_mono_data() failing), while after installing dotnet20 it's
REGDB_E_CLASSNOTREG.

-Daniel

On 22 July 2018 at 06:57, Nikolay Sivov <nsivov(a)codeweavers.com> wrote:
> Hi, Daniel.
>
> As far as I remember, from context side for clrClass case we add a module
> name as mscoree.dll, and the rest stays the same as with regular classes.
>
> On creation attempt, mscoree.DllGetClassObject is supposed to be called. Do
> you see this happening?
> If it gets to this point, try to install .NET framework (that will install
> native mscoree too), and see if that improves things.