In reference to bug #11973, I've the following observation.
Using the native .NET 2.0 installed via winetricks, I located what is
potentially a problem with the method that .NET is using to locate the DLLs
that it wishes to load.
The problem seems to be that .NET is attempting to locate the various DLL's it
is going to use, by searching various directory paths. Once this does not occur
(by placing a native DLL into the windows/system32 path) it causing a crash
further down. It doesn't seem to utilize the LoadLibrary initially to locate
but another function (from memory I think it NtCreateFile). With the native DLL
in place it starts to process properly, at least until it runs into other files
not located (as stated above).
I believe that .NET 2.0 is assuming that the files are located within the
directory path (this may be so that it can independently utilize application
supplied DLL files - I read that WinXP supposedly uses this policy to reduce
problems with DLL dependencies).
This of course, totally by-passes the built-in DLL files (which should be
located using this method, except that they do not exist in the paths .NET
searches).
There are two possible ways currently that I can think of, which would
potentially solve this problem:
1. Have symbolic links within the system directory (I find this to be bad
method, for multiple reasons)
2. Have some interception of the searching for files located within the
system32, to include all of built-in dlls.
Unfortunately, since I don't know a huge amount about Wine yet, I have no idea
on how to code the second one, and I think having a patch for this, may solve
quite a few problems that currently exist with using .NET based programs.
---------------------------------
Get the name you always wanted with the new y7mail email address.
