1

I had to rebuild the Krypton.Toolkit.dll from it's source in order to remove a license error message on runtime. In the references I have removed and replaced the old Krypton assemblies with the ones from source.

I am now getting the error: (and a related cast type error)

Could not load file or assembly 'ComponentFactory.Krypton.Toolkit, Version=4.0.0.0, Culture=neutral, PublicKeyToken=a87e673e9ecb6e8e'

I understand the error message. Although the my new reference has the same name it does not have a strong name at all, so there is no PublicKeyToken.

What I don't understand is why it's still looking for the old PublicKeyToken when the reference is being replaced completely? This DLL is not in the GAC.

At first these DLLs with matching PKT where referenced in my main projects .csproj file. I gave my two assemblies a strong name and replaced the old references.

I have then cleaned and rebuilt the project and the new strong name has been replaced in the csproj file. However Visual Studio is still looking for a87e673e9ecb6e8e in the aforementioned project, as shown in the error window.

Sorted. A reference was referencing the same 3rd party DLL as my project and they where conflicting.

Amicable
  • 3,115
  • 3
  • 49
  • 77

1 Answers1

1

Something in your solution seems to still hold a reference to the strong-named version.

You can open your .csproj (or I think .vbproj if you're doing VB) and look for that reference in your favorite text editor. Look for a line similar to:

<Reference Include="ComponentFactory.Krypton.Toolkit, Version=4.0.0.0, Culture=neutral, PublicKeyToken=a87e673e9ecb6e8e, processorArchitecture=MSIL">
</Reference>

Searching for the PublicKeyToken is probably sufficient.

If you find it, you will know which project still references the strong named version.

You may see a sub node like

<Reference ... >
  <HintPath>..\SomePath\ComponentFactory.Krypton.Toolkit.dll</HintPath>
</Reference>

directing the linker to look in a specific path to resolve the reference.

You can manually edit the project file (back it up first), or use that knowledge to update the reference through VS if you're more comfortable with that.

UPDATE

If it turns out (as it did in this case) that the issue is with a referenced DLL that in turn references the other Krypton version, a good tool for diagnosing the issue is the Fusion Log Viewer

http://msdn.microsoft.com/en-us/library/e74a18c4.aspx

Note that Fusion Log Viewer must run as Administrator. If not, it will not show any results but will otherwise not complain.

Eric J.
  • 147,927
  • 63
  • 340
  • 553
  • At first these where referenced in my main projects `.csproj` file, so I gave my two assemblies a strong name and replaced them. Clean and rebuilt the project and the new strong names have replaced `PublicKeyToken=a87e673e9ecb6e8e` but Visual Studio is still looking for `a87e673e9ecb6e8e` in the aforementioned project. – Amicable May 10 '12 at 16:24
  • There is no mention of `a87e673e9ecb6e8e` in your .csproj anymore? – Eric J. May 10 '12 at 16:37
  • There is not, but it appears that one of my other references that I don't have source access to is also referencing the Krypton Kit to. As when I remove the DLL the error message disappears. – Amicable May 11 '12 at 08:22
  • 1
    You can use the Fusion Log Viewer (FUSLOGVW) to diagnose that type of issue. Should probably have included that in the original answer. I'll update it in case it helps someone else. – Eric J. May 11 '12 at 17:06