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:[email protected]] 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" <[email protected]> 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? -- Alexandre Julliard [email protected]
