Can assembly identities be different for two copies of the same assembly?

Question

In that topics Difference between LoadFile and LoadFrom with .NET Assemblies? I found the next code:

Assembly assembly1 = Assembly.LoadFrom(path1);
Assembly assembly2 = Assembly.LoadFrom(path2);

// These both point to the assembly from path1, so this is true
Console.WriteLine(string.Compare(assembly1.CodeBase, assembly2.CodeBase) == 0);

I did that so:

    Assembly ass1 = Assembly.LoadFrom(Path.GetFullPath ("DataTypes.dll"));
    Assembly ass2 = Assembly.LoadFrom(Path.GetFullPath("test\\DataTypes.dll"));

    Console.WriteLine(ass1.CodeBase == ass2.CodeBase);

DataTypes.dll from folder test is the copy of DataTypes.dll from program folder. It is expected that result would be true, but my program show FALSE. If it is needed I can give any information for explanation.

That is your problem. You will need strong-named assemblies so that their identities can be compared. — mgronber, Nov 22 '11 at 08:51

score 2 · Accepted Answer · answered Nov 22 '11 at 08:31

It's from a different copy therefore it's a different codebase. If they have the same stong name then they are the same as far as the calling assembly is concerned. Aside from a binary compare of the file, I' can't see how you can guarantee the equivalance you are looking for.

Peter PAD · Answer 2 · 2011-11-22T09:16:50.673

2

I had a solution for your question

You put your assemblies in two folders, but the same assembly,

        var asmPath = AppDomain.CurrentDomain.BaseDirectory; // Your assemblies's root folder
        var asmFullPath1 = System.IO.Path.Combine(asmPath, @"test\ClassLibrary1.dll");
        var asmFullPath2 = System.IO.Path.Combine(asmPath, @"test2\ClassLibrary1.dll");
        Assembly asm1 = System.Reflection.Assembly.LoadFrom(asmFullPath1);
        Assembly asm2 = System.Reflection.Assembly.LoadFrom(asmFullPath2);
        Console.WriteLine(asm1.CodeBase == asm2.CodeBase);

You will got the same CodeBase

To find more information about CodeBase

http://msdn.microsoft.com/en-us/library/system.reflection.assembly.codebase.aspx

edited Nov 22 '11 at 09:16

answered Nov 22 '11 at 08:35

Peter PAD

2,252
1
17
20

Comparing of locations displays fals too. – Tadeusz Nov 22 '11 at 08:53
Even if you get to codebase1 = codebase2, what does that actually mean? That the dlls are exactly the same?. Nope. All depends on what @Praetor12 is trying to achieve with codebase1 =- codebase2. – Tony Hopkinson Nov 23 '11 at 13:39
Sort of , but location counts. What if they are exactly the same but one came from a remote source? Unless I was checking for say updating a build or deployment, to me sameness is misleading. – Tony Hopkinson Nov 26 '11 at 16:32

score 1 · Answer 3 · answered Nov 22 '11 at 08:36

1

The MSDN definition of CodeBase:

The location of the assembly as specified originally

You might want to compare assembly.Location instead.

answered Nov 22 '11 at 08:36

jgauffin

99,844
45
235
372

Andras Zoltan · Answer 4 · 2011-11-22T08:55:05.560

As Tony has said - the two assemblies have been loaded from different Codebases (i.e. locations on disk or, indeed, on a LAN or WAN) and therefore not only does .Net load both (dumbly - but not in itself dumb), but it will also see each assembly as being different - with each duplicate type in each assembly being considered different.

It's for this reason that I use LoadFrom with extreme caution, because it will quite happily load the same assembly from different locations.

This is a phenomenon that can also occur - with quite drastic results - in websites where, if pre-loading assemblies, the tempation is to pre-load from the bin\ folder using LoadFrom, whereas in actual fact the aqssemblies will typically be loaded normally from the Temporary Asp.Net Folder (TempASP).

In this scenario it's possible to pre-load AssemblyA from bin\AssemblyA.dll and then the runtime loads it again from TempASP\AssemblyA.dll because that folder is first in the search path used by Load. This can lead to really nasty side-effects such as InvalidCastExceptions being thrown on compiled portions of code that you would think couldn't possibly raise an error normally.

If comparing equality, then the binary compare, as Tony has suggested, is your best bet. If you're actually just looking to load one of the copies of these assemblies, however, then you should consider getting the AssemblyName from the DLL first (there is a constructor for that that doesn't load the assembly) and then passing that name to Assembly.Load - which will then load it from the correct place.

Can assembly identities be different for two copies of the same assembly?

4 Answers4