Проект Ссылки DLL версия ад
У нас проблемы с тем, чтобы Visual Studio выбрала последнюю версию DLL из одного из наших проектов.
У нас есть несколько проектов библиотек классов (например, BusinessLogic, ReportData) и несколько веб-служб, каждый из которых имеет ссылку на DLL-библиотеку подключений, которую мы написали (эта ссылка на DLL-подключаемость является проблемой).
Мы всегда указываем ссылки на DLL в папке bin/debug (это то место, где мы всегда собираемся для любого данного проекта), и все пользовательские ссылки на DLL имеют CopyLocal = True и SpecificVersion = False
ReportData имеет ссылку на бизнес-логику (которая также имеет ссылку на связь - я не понимаю, почему это должно вызывать проблемы, но подумал, что стоит упомянуть)
Странно то, что когда вы нажимаете "Добавить ссылку" и просматриваете Connectivity / bin/debug - вы наводите курсор мыши на файл DLL, отображается правильная (последняя) версия (версия и версия файла всегда увеличиваются вместе), но когда вы нажимаете ОК, предыдущий номер версии вытягивается, хотя. Даже когда я смотрю в папку отладки текущих проектов (куда локальная копия поместит DLL после компиляции), в которой отображается номер последней версии. - НЕТ, ГДЕ я могу найти предыдущую версию DLL за пределами Visual Studio, но в ссылках на этот проект она имеет старую версию - даже если путь правильный.
Я в недоумении относительно того, откуда он может получить старые версии. Или даже почему он этого хочет.
Это, возможно, самая неприятная проблема, с которой я когда-либо сталкивался.
Кто-нибудь знает, как обеспечить загрузку последней версии (желательно автоматически или при компиляции).
РЕДАКТИРОВАТЬ:
Хотя это не совсем тот сценарий, с которым я имею дело, я читал эту статью и где-то упоминалось, что CLR игнорирует номера ревизий. Понятно (хотя раньше это не было проблемой - у нас редакция 39), поэтому я подумал, что обновлю номер сборки, но все равно не сработало. В тщетной попытке я решил обновить младший номер версии и посмотреть, будет ли это иметь значение.
Я не говорю, что это ответ, так как сначала я должен проверить несколько вещей, но на первый взгляд это, похоже, решило мою проблему...
Дальнейшее редактирование: в других библиотеках классов это, похоже, решило проблему, однако в тестовом приложении Windows оно по-прежнему тянет предыдущую версию через:(
Если я снова увеличу младший номер версии, снова возникнет та же проблема, и у меня останется неверная версия.
Дальнейшее редактирование - я создал совершенно новый проект, добавил ссылку и все еще имел ту же проблему. Это говорит о том, что проблема ограничена проектом, на который я ссылаюсь. Хотел бы я знать почему!
У кого-нибудь была такая проблема раньше и знаете, как ее обойти?
ПОМОГИТЕ!
11 ответов
Чтобы преодолеть это, я удалил КАЖДУЮ ссылку, а затем добавил их снова. Я не знаю, почему это решение.
Возможно, что в одном проекте DLL была неправильной, и именно эта неправильная DLL была проверена Visual Studio и использована.
Изменить: В других случаях эта ошибка произошла из-за DDL (A), на который ссылается в текущем проекте, также ссылается другой DLL (B). Невозможность перестроить эту другую DLL (B), по-видимому, не позволяет VS ссылаться на правильную версию DLL (A) в текущем проекте, и, таким образом, она переносит более старую версию DLL (A).
Чтобы избежать ада, я бы порекомендовал вам создать lib папку внутри вашего проекта и поместите все общие сборки в эту папку. Далее вы добавляете ссылки только из этой папки. Таким образом, ваш проект самодостаточен, и вы точно знаете, откуда он берет ссылки. Если вы хотите обновить сборку более новой версией, скопируйте ее в lib папку и пересоберите свой проект.
Также убедитесь, что вы не ссылаетесь на сборки в GAC, так как они могут быть подобраны первыми.
Есть несколько вариантов, которые вы можете попробовать.
- Скомпилируйте проект и посмотрите в окне вывода, чтобы точно проверить путь сборки, на который он ссылается.
- Удалите папку Obj, прежде чем перекомпилировать ее.
- Закройте и снова откройте Visual Studio, поскольку VS имеет странное поведение, чтобы сохранить кеш для хранения ссылок Dll.
- Если вы все еще видите проблему, используйте этот инструмент, чтобы проверить эталонную сборку, откуда она на самом деле. Process Explorer.
Мы (и, как я имею в виду, единственный разработчик.NET в нашей команде) столкнулись с точно такой же проблемой. Я проследил это до ссылочной dll, которая в свою очередь снова ссылается на dll, страдающую версионитом. Кажется, потому что я не обновлял все ссылки, которые в свою очередь ссылаются на dll, он был заменен более старой версией в какой-то момент в процессе сборки.
Один из симптомов, с которыми я столкнулся, заключался в том, что, когда я нахожусь в редакторе кода, новый класс, который я добавил в ссылочный проект, будет окрашен соответствующим образом, но когда я нажму Build, он изменится на черный, и я получу сообщение о том, что класс делает не существует (наряду с очень саркастическим "Ar, вы пропустили ссылку на сборку?"). Это заставило меня поверить, что проблема должна возникнуть на этапе сборки.
Поэтому я бы предложил создать любой и любой другой проект, который указывает на эту DLL, и снова добавить их ссылки.
Вы пытались добавить ссылку в качестве ссылки на проект? т.е. Добавить ссылку... -> вкладка "Проекты" -> выбрать проект
У нас очень похожая проблема с WPFToolkit. Мы только что обновились до выпуска февраля 2010 года (используя MSI 5 марта). "Добавить ссылки" показывает правильные файлы в правильном месте, но перечисляет старые версии #s. Однако физические файлы имеют правильную версию #. Удалил, удалил вручную любые ссылки WPFToolkit из реестра и т. Д., Но безрезультатно. Должно быть, где-то это кешируется, но мы пока не можем этого понять. Тратить часы на это.
У меня была проблема, подобная описанной здесь, за исключением того, что мое решение проблемы было связано с тем, как я компилировал код. Существует разница между сборкой, очисткой и перестройкой. В моем случае я просто использовал Build между своими изменениями, и dll из зависимого решения не переносился со всеми изменениями в другое решение, где была установлена ссылка. Я решил это с помощью Rebuild, который очищает, компилирует и связывает все исходные файлы независимо от того, изменились они или нет. Затем DLL из первого решения была обновлена и автоматически скопирована во 2-е решение, где была установлена ссылка и проблема была решена. Ура, я надеюсь, что это помогает.
Проверьте это вещи:
- если на проблемную 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 в bin проекта класса файла xyz.dll.
Надеюсь, вышеперечисленные детали помогут, удачи
Аналогичные симптомы - проблема была в "Реферальных путях" в Свойствах проекта, Ссылка.
Полное описание и решение здесь: Ссылочные сборки автоматически заменяются на visual studio visual-studio / 22810867 # 22810867
Включите FusionLog и после сбоя загрузки DLL откройте файл с именем DLL в папке C:\FusionLog\Default\devenv.exe. Это покажет путь, откуда DLL была действительно загружена.
В моем случае старая версия загадочно появилась в
C:\Program Files\Microsoft Visual Studio 10\Common7\IDE!
Чтобы это никогда не повторилось, я добавил правило безопасности "Запретить запись" для всех в Common7\IDE.
Одной из возможных причин являются контрольные пути. Если есть какая-либо ссылка на старую папку DLL, VS будет использовать ее в качестве основной ссылки, даже если вы добавили новую ссылку DLL.