Ссылка на проект DLL версия hell

У нас возникают проблемы с визуальной студией, чтобы забрать последнюю версию DLL из одного из наших проектов.

У нас есть несколько проектов библиотеки классов (например, BusinessLogic, ReportData) и ряд веб-сервисов, каждая из которых имеет ссылку на DLL Connectivity, которую мы написали (эта ссылка на DLL для подключения является проблемой).

Мы всегда указываем ссылки на DLL в папке bin/debug (где мы всегда строим для любого данного проекта), и все пользовательские DLL-ссылки имеют CopyLocal = True и SpecificVersion = False

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

Странно, когда вы нажимаете "Добавить ссылку" и переходите к Connectivity/bin/debug - вы наводите мышку на DLL файл, отображается правильная (последняя) версия (версия и версия файла всегда увеличиваются вместе), но когда вы нажимаете ok, последний номер версии потянут. Даже когда я смотрю в текущей папке отладки проектов (где скопировать локальную библиотеку DLL после компиляции), которая показывает номер последней версии. - Нет. ГДЕ я могу найти предыдущую версию DLL за пределами visual studio, но в этом проекте ссылки у нее есть старая версия - хотя путь правильный.

Я не понимаю, откуда можно получить старые версии. Или даже почему он хочет этого.

Это, возможно, самая неприятная проблема, с которой я когда-либо сталкивался.

Кто-нибудь знает, как обеспечить прохождение последней версии (желательно автоматически или при компиляции).

EDIT:

Хотя это не совсем тот сценарий, с которым я столкнулся, я читал эту статью, и где-то он упоминает о том, что CLR игнорирует номера версий. Понятно (хотя это не было проблемой раньше - мы находимся в редакции 39), поэтому я думал, что обновить номер сборки, все равно не сработал. В тщетной попытке, хотя я бы обновил номер второстепенной версии и посмотрел, не изменилось ли это.

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

Дальнейшее редактирование: В других библиотеках классов это, похоже, решило проблему, однако в приложении для тестовых окон она по-прежнему вытаскивает предыдущую версию через: (

Если я снова увеличиваю номер второстепенной версии, та же проблема вернется, и я остаюсь с неправильной версией, которую вытаскивают.

Дальнейшее редактирование - я создал новый проект, добавил ссылку и все еще имел ту же проблему. Это говорит о том, что проблема ограничена проектом, на который я ссылаюсь. Хотел бы я знать, почему!

У кого-то была эта проблема раньше и знаете, как обойти ее?

HELP!

Ответы

Ответ 1

Чтобы преодолеть это, я удалил КАЖДУЮ ссылку, а затем снова добавил их обратно. Я не знаю, почему это решение.

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

Изменить: В других случаях эта ошибка произошла из-за того, что DDL (A) ссылается в текущем проекте, на который ссылается другая DLL (B). Не перестраивать эту другую DLL (B), похоже, не позволяет VS ссылаться на правильную версию DLL (A) в текущем проекте и, таким образом, она использует более старую версию DLL (A).

Ответ 2

Чтобы избежать атак dll, я бы рекомендовал вам создать папку lib внутри вашего проекта и поместить все общие сборки в эту папку. Затем вы добавляете ссылки только из этой папки. Таким образом, ваш проект является самодостаточным, и вы точно знаете, где он выбирает ссылки. Если вы хотите обновить некоторую сборку новой версией, скопируйте ее в папку lib и перестройте свой проект.

Также убедитесь, что вы не ссылаетесь на сборку в GAC, поскольку они могут быть подняты в первую очередь.

Ответ 3

Есть несколько вариантов, которые вы можете попробовать.

  • Скомпилируйте проект и посмотрите в окне вывода, чтобы проверить путь сборки, где он точно указан.
  • Удалите папку Obj, прежде чем перекомпилировать ее.
  • Закройте и заново откройте Visual Studio, так как VS имеет какое-то странное поведение, чтобы сохранить в кэше ссылки Dll.
  • Если вы все еще видите проблему, используйте этот инструмент, чтобы проверить ссылочную сборку, где она исходит. Process Explorer.

Ответ 4

Вы пытались добавить ссылку в качестве ссылки на проект? то есть Добавить ссылку... → вкладка "Проекты" → Выберите свой проект

Ответ 5

Мы (и, как единственный разработчик .NET в нашей команде, я имею в виду I), имели ту же самую проблему. Я проследил его до ссылки dll, которая, в свою очередь, AGAIN ссылается на dll, страдающую от версий. Похоже, что, поскольку я не обновлял все ссылки, которые, в свою очередь, ссылаются на dll, в какой-то момент процесса сборки он был заменен более старой версией.

Один из симптомов, которые я испытал, заключался в том, что когда я нахожусь в редакторе кода, новый класс, который я добавил в ссылочный проект, будет соответствующим образом окрашен, но когда я нажму Build, он изменится на черный, и я получаю сообщение о том, что класс не существует (наряду с очень саркастическим "Ар, у вас отсутствует ссылка на сборку?" ). Это заставило меня поверить, что проблема должна произойти на этапе сборки.

Поэтому я бы предложил создать любой другой проект, который указывает на эту DLL, и снова добавить ссылки.

Ответ 6

У нас очень похожая проблема с WPFToolkit. Мы только что обновились до выпуска в феврале 2010 года (с использованием 5 марта msi). "Добавить ссылки" показывает правильные файлы в правильном месте, но перечисляет старую версию #s. Однако физические файлы имеют правильную версию #s. Удалили, вручную удалили любые ссылки WPFToolkit из реестра и т.д., Но безрезультатно. Это должно быть кеширование этого материала, но мы еще не смогли его понять. Тратить часы на это.

Ответ 7

Включить FusionLog и после того, как DLL не загрузится, откройте файл с именем DLL в папке C:\FusionLog\Default\devenv.exe. Это покажет путь, из которого была загружена DLL.

В моем случае старая версия загадочно появилась в

C:\Program Files\Microsoft Visual Studio 10\Common7\IDE!

Чтобы это снова не происходило, я добавил правило безопасности "Запретить запись" всем на Common7\IDE.

Ответ 8

У меня была проблема, аналогичная описанной здесь, за исключением того, что мое решение проблемы связано с тем, как я компилировал код. Существует разница между сборкой, очисткой и перестройкой. В моем случае я просто использовал Build между моими изменениями, а dll из зависимого решения не переносились со всеми изменениями в другое решение, где была установлена ​​ссылка. Я решил это, используя Rebuild, который очищает, компилирует и связывает все исходные файлы независимо от того, изменились они или нет. Затем dll из первого решения была обновлена ​​и автоматически скопирована на второе решение, где была установлена ​​ссылка, и проблема была решена. Приветствия, надеюсь, это поможет.

Ответ 10

Проверьте это:

  • если проблемная dll была указана как хост-веб-приложением, так и ссылкой на него. например скажем, ваше веб-приложение использует abc.dll(проблематично) и еще 1 dll xyz.dll(например, проект класса, который также ссылается на abc.dll).

В этом случае, предположим, вы обновили abc.dll с версии 1 до версии 2 и повторно указали в своем веб-приложении. но во время процесса сборки версия 2 abc.dll вернется к версии 1, потому что xyz.dll использует версию 1, а веб-приложение перезаписывает abc.dll версии 2 обратно в abc.dll версии 1 во время автоматического обновления на xyz.dll.

Решение: поместите обновленную версию abc.dll версии 2 в ящик проекта проекта xyz.dll, тоже

Надежда, выше подробностей поможет, удача

Ответ 11

Одна из возможных причин - это ссылки PATH. Если есть ссылка на старую папку dll, VS будет использовать ее в качестве основной ссылки, даже если вы добавили новую ссылку dll.