[1/3] mscoree: Add tests for LoadLibraryShim.

[Vincent Povirk]

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 at 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 at 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?

-- 
Alexandre Julliard
julliard at winehq.org