2012-05-10 2 views
1

Мне пришлось перестроить Krypton.Toolkit.dll из его источника, чтобы удалить сообщение об ошибке лицензии во время выполнения. В ссылках я удалил и заменил старые сборки Криптона теми, которые были из источника.VS нацелился на неправильную сборку

Сейчас я получаю сообщение об ошибке: (и связанный типа ошибку литого)

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

Я понимаю, сообщение об ошибке. Хотя моя новая ссылка имеет то же имя, у нее нет сильного имени, поэтому PublicKeyToken отсутствует.

Что я не понимаю, почему он все еще ищет старый PublicKeyToken, когда ссылка полностью заменяется? Эта DLL не находится в GAC.


Сначала эти библиотеки DLL с соответствующим ПКТОМ, где ссылаются в своих основных проектах .csproj файлов. Я дал своим двум ассамблеям сильное имя и заменил старые ссылки.

Затем я очистил и перестроил проект, а новое сильное имя было заменено в файле csproj. Однако Visual Studio по-прежнему ищет a87e673e9ecb6e8e в вышеупомянутом проекте, как показано в окне ошибки.


Сортировка. Ссылка ссылалась на ту же самую стороннюю DLL, что и на мой проект, и они конфликтуют.

ответ

1

Что-то в вашем решении, похоже, все еще содержит ссылку на сильную версию.

Вы можете открыть свой .csproj (или я думаю .vbproj, если вы делаете VB) и искать эту ссылку в своем любимом текстовом редакторе. Посмотрите на строку, похожую на:

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

Возможно, для поиска в PublicKeyToken достаточно.

Если вы нашли это, вы узнаете, какой проект по-прежнему ссылается на сильную именованную версию.

Вы можете увидеть вспомогательный узел, как

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

предписывающего линкер смотреть в определенном пути, чтобы решить эту ссылку.

Вы можете вручную отредактировать файл проекта (сначала создать резервную копию) или использовать эти знания для обновления ссылки через VS, если вам более удобно с этим.

UPDATE

Если оказывается (как это было в данном случае), что проблема с ссылочного DLL, которые в свою очередь, ссылается на другую версию криптон, хороший инструмент для диагностики проблемы является Fusion Log Viewer

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

Обратите внимание, что Fusion Log Viewer необходимо запуск от имени администратора. Если нет, он не будет показывать никаких результатов, но в противном случае не будет жаловаться.

+0

Спасибо, это именно то, что я искал, чтобы узнать :) – Amicable

+0

Сначала они ссылаются на мои основные проекты '.csproj', поэтому я дал свои две сборки сильное имя и заменил их. Очистить и перестроить проект, а новые сильные имена заменили «PublicKeyToken = a87e673e9ecb6e8e», но Visual Studio по-прежнему ищет «a87e673e9ecb6e8e» в вышеупомянутом проекте. – Amicable

+0

У вас нет упоминания 'a87e673e9ecb6e8e' в вашем .csproj? –

Смежные вопросы