Well, I don't think we can do it properly without having multiple instances of a builtin dll.
I believe that native fusion.dll is different for each .NET version, and it probably has the version number baked in.
If we can't have multiple instances of a builtin dll, I still believe testing the path is the best way to determine which version was given to LoadLibraryShim, if that's possible.
If testing the path is not possible, we can have LoadLibraryShim use a wine-specific exported function to inform fusion.dll of the version, but this approach won't work if someone loads fusion.dll directly from a .NET system directory.
There is another minor problem highlighted by this test, which is that I can make up any path and end up with a loaded dll, as long as there's a builtin dll filename at the end.
-----Original Message----- From: Alexandre Julliard [mailto:julliard@winehq.org] Sent: Wednesday, October 27, 2010 1:31 PM To: Vincent Povirk Cc: WineHQ Development Mailing List Subject: Re: [1/3] mscoree: Add tests for LoadLibraryShim.
"Vincent Povirk" vincent@codeweavers.com writes:
This is needed so that fusion.dll can find out which .NET version it's expected to use without loading mscoree.dll. Native has the capability of loading multiple .NET versions in a single process, so the current approach is unworkable.
Testing the filename doesn't seem much more workable, you can't load multiple instances of a builtin dll anyway. How are you planning to handle this?
"Vincent Povirk" vincent@codeweavers.com writes:
There is another minor problem highlighted by this test, which is that I can make up any path and end up with a loaded dll, as long as there's a builtin dll filename at the end.
That's a feature, the idea is that builtin dlls are independent from the actual dll files. That's also why asking for the path name of a builtin doesn't make sense.
This could conceivably be changed now that we have the fake dlls mechanism, but it would be a pretty fundamental redesign.
-
Alexandre Julliard -
Vincent Povirk