[Mono-dev] Bug: Assembly object's FullName ignores PublicToken

[Jb Evain]

Hi,

Here are two patches, one to the runtime, the other to the corlib.
The patch to corlib breaks some tests which assert on the behavior 
described here, so I don't want to commit it as it is.

But I'd like to know, should not we use an icall which would call 
mono_stringify_assembly_name to avoid code duplication?

Jb

Alex Chudnovsky wrote:
> Hi all,
> 
> I've come across with what appears a bug (more precisely different 
> behavior from .NET 1.1 framework on Windows) in loaded assembly's 
> FullName, here is the output I get when I run DLL on Linux using Mono 
> v1.1.17.1 (SuSe from official VMware image):
> 
> Mono:      MyDllName, Version=1.0.0.0, Culture=neutral
> Windows: MyDllName, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
> 
> Anyone else gets that? This happened for a DLL explicitly loaded using 
> Assembly.LoadFrom(), but I verified that it happens when just checking 
> executing assembly, try this for test purposes:
> 
> Console.WriteLine("Asm: {0}",Assembly.GetEntryAssembly().FullName);
> 
> The issue here is that any code that relies on using FullName string 
> comparisons to ascertain that present DLL is exactly the same as 
> required will fail
> 
> Assemblies are not strong named, so key token should be null, perhaps 
> that's why it was not added to the string?
> 
> cheers
> 
> Alex
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: AssemblyName.diff
Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060927/1c3fb952/attachment.pl 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: metadata.diff
Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060927/1c3fb952/attachment-0001.pl