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

Question

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

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

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

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

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

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

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

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

EDIT:

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

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

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

Если я снова увеличу младший номер версии, снова возникнет та же проблема, и у меня останется неверная версия.

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

Кто-нибудь имел эту проблему раньше и знает, как ее обойти?

HELP!

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

1. Скомпилируйте проект и посмотрите в окне вывода, чтобы точно проверить путь сборки, на который он ссылается.
2. Удалите папку Obj перед перекомпиляцией.
3. Закройте и снова откройте Visual Studio, поскольку VS имеет странное поведение, чтобы сохранить кеш для хранения ссылок Dll.
4. Если вы все еще видите проблему, используйте этот инструмент для проверки эталонной сборки, откуда она на самом деле. Process Explorer .

Answer 4

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

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

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

Answer 5

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

Answer 6

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

Answer 7

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

Answer 8

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

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

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

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

Надеюсь, вышеперечисленные детали помогут, удачи

Answer 9

Аналогичные симптомы - проблема была в "Реферальных путях" в свойствах проекта, ссылка.

Полное описание и решение здесь: Ссылочные сборки автоматически заменяются Visual Studio зрительно-студия / 22810867 # 22810867

Answer 10

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