When probing for assemblies why does the searched for publicKeyToken differ when running as admin vs as a normal user?

Question

I'm following instructions from a 2006 Microsoft .Net course workbook, going through one of the exercises. (Specifically this course is MS2349B and I'm doing Module 4 Exercise 2.). These exercises seem to built for the pre Vista days when everyone has full admin privileges all the time. (I'm using .net 4.0.)

This exercise involves building a strong name assembly, installing it in the GAC, building a local executable against the strong named assembly, verifying that the executable runs.

As per the tutorial, I sign my assembly using a #if block:

#if STRONG
[assembly: System.Reflection.AssemblyVersion("2.0.0.0")]
[assembly: System.Reflection.AssemblyKeyFile("OrgVerKey.snk")]
#endif

I build my executable as a local user:

C:\path\to\lab>csc /define:STRONG /target:library 
 /out:AReverser_v2.0.0.0\AReverser.dll AReverser_v2.0.0.0\AReverser.cs
C:\path\to\lab>csc /reference:MyStringer\Stringer.dll     
 /reference:AReverser_v2.0.0.0\AReverser.dll Client.cs

I install it into the GAC via a visual studio command prompt run as administrator:

C:\path\to\lab>gacutil /i AReverser_v2.0.0.0\AReverser.dll

When I run my exe in the administrator prompt I get the output I expect -- the application runs fine and appears to load the dll correctly from the gac. When I run under the non-admin command prompt I get the following error

Unhandled Exception: System.IO.FileLoadException: Could not load file or assembl
y 'AReverser, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b5fcbdcff229fabb'
 or one of its dependencies. The located assembly's manifest definition does not
 match the assembly reference. (Exception from HRESULT: 0x80131040)
   at MainApp.Main()

What's odd to me is that the publicKeyToken is not the same as what's in the GAC:

AReverser, Version=2.0.0.0, Culture=neutral, PublicKeyToken=f0548c0027634b66

BUT if I uninstall AReverser from the GAC and attempt to run my exe as admin prompt I get the following error which indicates its looking for the expected public key token f0548c0027634b66:

C:\path\to\lab>gacutil /u "AReverser,Version=2.0.0.0,Culture=neutral,
PublicKeyToken=f0548c0027634b66"
Microsoft (R) .NET Global Assembly Cache Utility.  Version 4.0.30319.1
Copyright (c) Microsoft Corporation.  All rights reserved.


Assembly: AReverser, Version=2.0.0.0, Culture=neutral, PublicKeyToken=f0548c0027
634b66
Uninstalled: AReverser, Version=2.0.0.0, Culture=neutral, PublicKeyToken=f0548c0
027634b66
Number of assemblies uninstalled = 1
Number of failures = 0

C:\path\to\lab>Client.exe

Unhandled Exception: System.IO.FileLoadException: Could not load file or assembl
y 'AReverser, Version=2.0.0.0, Culture=neutral, PublicKeyToken=f0548c0027634b66'
 or one of its dependencies. The located assembly's manifest definition does not
 match the assembly reference. (Exception from HRESULT: 0x80131040)
   at MainApp.Main()

Notice under Admin, its actually searching for the correct publicKeyToken.

What gives? Why would the searched for publickKeyTokens differ? What could I have done wrong?

EDIT

The app config we're told to use may be the culprit, I'm wondering if you have to be admin to apply some of these settings. Getting rid of it seems to cause running as admin to fail (although in that case publicKeyToken is listed as NULL). Here's my app config

<configuration>   
    <runtime>
        <assemblyBinding
            xmlns="urn:schemas-microsoft-com:asm.v1">
            <probing privatePath="MyStringer"/>
            <publisherPolicy apply="no"/>
            <dependentAssembly>
                <assemblyIdentity name="AReverser" 
                    publicKeyToken="f0548c0027634b66" 
                    culture=""/>
                <publisherPolicy apply="no"/>
                <bindingRedirect oldVersion="2.0.0.0" 
                    newVersion="2.0.0.0"/>
            </dependentAssembly>
        </assemblyBinding>
    </runtime>
</configuration>

Answer 1

Search your disk for AReverser.dll. It is possible that you have some additional copies somewhere hidden. VS can make shadow copies of compiled dlls.

If that doesn't help activate fusion logging (use fuslogvw.exe or spool fusion logs to disk) and then look in logs where the problematic dll is loaded from. IMO it is the wrong dll that is loaded.