У нас есть проблемы, заставляя 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 к проекту, на который я ссылаюсь. Желание я знал почему!
У кого-либо была эта проблема прежде, и знайте, как обойти ее?
На помощь!
У нас возникла очень похожая проблема с WPFToolkit. Мы только что обновились до версии, выпущенной в феврале 2010 г. (с использованием MSI-файла от 5 марта). «Добавить ссылки» показывает правильные файлы в правильном месте, но перечисляет старые версии #s. Однако физические файлы имеют правильные номера версий. Удалили, вручную удалили все ссылки WPFToolkit из реестра и т. Д., Но безрезультатно. Должно быть, он где-то кеширует этот материал, но мы еще не смогли это выяснить. Тратить на это часы.
Чтобы избежать ада dll , я бы рекомендую вам создать папку lib
внутри вашего проекта и поместить все общие сборки в эту папку. Затем вы добавляете ссылки только из этой папки. Таким образом, ваш проект является самодостаточным, и вы точно знаете, откуда он берет ссылки. Если вы хотите обновить какую-либо сборку до более новой версии, скопируйте ее в папку lib
и пересоберите свой проект.
Также убедитесь, что вы не включили сборки, на которые есть ссылки, в GAC, так как они могут быть подобраны первыми.
Есть несколько вариантов, которые вы можете попробовать.
Пробовали ли вы добавить ссылку как ссылку на проект? Т.е. Добавить ссылку... -> вкладка Проекты -> Выберите свой проект