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
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.
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@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.
-
Daniel Kamil Kozar -
Nikolay Sivov