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

[Vincent Povirk]

Well, in practice, it's a detail that I don't expect to be very important, so it's probably not worth the trouble. Mostly I just want to elminiate the call fusion makes back into mscoree, since it is so blatantly wrong and causes the change I really want to break the tests. We could probably even get away with a hard-coded path, since our ngen.exe doesn't work anyway, and that's essentially what we're doing now given the semi-stub status of GetCORVersion.

If/when we need to use the CLR version in fusion for something other than finding the precompiled assembly cache, this may become more important, but even then I don't think we'll need multiple simultaneous instances to work properly. We'll just need to know the correct version to use when only one instance is loaded. Multiple simultaneous runtimes is a case I'm thinking about and trying to account for, but I don't expect to ever see it used.

If you prefer, I can add a test for fusion instead that compares the version we get out of GetCachePath(ASM_CACHE_ZAP) to the one we pass to LoadLibraryShim, in cases where more than one runtime is installed, assuming only one instance will be loaded at once. I can fix that without any changes to the loader, but it will mean adding a wine-specific export to fusion.

OR mscoree could lie about which .NET versions are installed when Mono isn't available, until there's a real need to load Mono.

-----Original Message-----
From: Alexandre Julliard [mailto:julliard at winehq.org] 
Sent: Wednesday, October 27, 2010 2:15 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:

> 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
julliard at winehq.org