This seems suspicious to me. You appear to be taking the namespace of the class and assuming it's an assembly name.
Is there really no other information in the registry that could be used to identify the assembly?
Hi Vincent, there's no more info in the registry. At this point we have the assembly name and we know that it is not in GAC, so either it is in current directory or it's absent.
That being said, I think this is the wrong place for this change. Method get_file_from_strongname [1] is better suited for that purpose IMO. Also MSDN states that assembly name is not equivalent to file name. I suppose that code to resolve assembly name into file name exists somewhere in fusion.dll, but I have never seen it. Hans may know more.
Regards, Daniel
[1] http://source.winehq.org/source/dlls/mscoree/metahost.c#L1213
2013/8/14 Vincent Povirk madewokherd@gmail.com
This seems suspicious to me. You appear to be taking the namespace of the class and assuming it's an assembly name.
Is there really no other information in the registry that could be used to identify the assembly?
If we have the assembly name, then we should be using that to decide on the filename to try in the application directory, not the namespace.
On Wed, Aug 14, 2013 at 4:04 PM, Daniel Jeliński djelinski1@gmail.com wrote:
That being said, I think this is the wrong place for this change. Method get_file_from_strongname [1] is better suited for that purpose IMO.
Doing it that way is probably more correct, but it's also more dangerous because it would affect all assembly lookups. We'd then want to check the precedence of dll's in the application directory vs. the GAC, what happens when the filename matches but the strongname does not, and whether other directories in the dll search path should be considered.
On 15/08/2013 2:41 AM, Vincent Povirk wrote:
This seems suspicious to me. You appear to be taking the namespace of the class and assuming it's an assembly name.
Is there really no other information in the registry that could be used to identify the assembly?
I'll have another look to see if it can be done a better way.
Alistair.