Ссылки проекта ад версии DLL

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

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

Мы всегда указываем на ссылки на DLL в мусорном ведре/папке отладки, (который является, где мы всегда создаем к для любого данного проекта), и все пользовательские ссылки DLL имеют CopyLocal = Верный и SpecificVersion = Ложь

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

Странная вещь при нажатии на "Add Reference" и обзор к Возможности соединения/мусорному ведру/отладке - Вы нависаете мышь над файлом DLL, корректную (последнюю) версию показывают (версия, и версия файла всегда увеличиваются вместе), но когда Вы нажимаете ОК, предыдущий номер версии вытягивают все же. Даже когда я смотрю в текущей папке отладки проектов (куда локальная копия поместила бы DLL после компиляции), который показывает число последней версии. - НЕТ, ГДЕ делает банку, я нахожу предыдущую версию DLL за пределами Visual Studio, но в котором ссылки проекта это имеет старую версию - даже при том, что путь корректен.

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

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

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

Править:

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

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

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

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

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

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

На помощь!

19
задан Mr Shoubs 4 March 2010 в 09:27
поделиться

4 ответа

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

1
ответ дан 21 October 2019 в 00:00
поделиться

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

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

37
ответ дан 30 November 2019 в 02:18
поделиться

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

  1. Скомпилируйте проект и посмотрите в окне вывода, чтобы проверить путь сборки, откуда на него ссылаются.
  2. Удалите папку Obj перед ее перекомпиляцией.
  3. Закройте и снова откройте Visual Studio, так как VS ведет себя странно, сохраняя в кеше ссылки на Dll.
  4. Если вы все еще видите проблему, используйте этот инструмент, чтобы проверить эталонную сборку, откуда она на самом деле. Обозреватель процессов .
9
ответ дан 30 November 2019 в 02:18
поделиться

Пробовали ли вы добавить ссылку как ссылку на проект? Т.е. Добавить ссылку... -> вкладка Проекты -> Выберите свой проект

2
ответ дан 30 November 2019 в 02:18
поделиться
Другие вопросы по тегам:

Похожие вопросы: