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