CODEWITHSUNDEEP
visual-studio-2010assemblieskrypton-toolkit
Amicable
Amicable

Reputation: 3101

VS targeting wrong assembly

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.

Upvotes: 1

Views: 2212

Answers (1)

Eric J.
Eric J.

Reputation: 150148

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.

Upvotes: 1

Related Questions