Решение с несколькими проектами, зависящими от одной и той же двоичной ссылки

Question

У меня есть решение с 10 проектами. Многие проекты зависят от сторонней библиотеки DLL с именем foo.dll.

Проблема в том, что когда я обновляю foo, то как-то в Visual Studio, когда я захожу в Object Browser, он показывает мне две версии foo.dll.

Как узнать, какой проект ссылается на старую версию foo.dll, чтобы я мог обновить ее, чтобы во всех проектах была только одна зависимость?

Answer 1

Это то, что вы хотите сделать только один раз.

Я рекомендую вам взять блокнот. Да, Блокнот.

Откройте файл .csproj для каждого из ваших проектов.

В XML будет раздел с описанием библиотеки DLL, на которую ссылаются, включая путь и т. Д. Даже если они выходят из GAC, будет включена версия и т. Д., Используемая компоновщиком .NET. в файле. Вся строка ссылки должна точно соответствовать.

Сравните их с одним проектом, который вы знаете, чтобы быть правильным.

Работа со ссылками в .NET - одна из худших его частей. Добро пожаловать в DLL ад v2.0: (

Answer 2

У меня была такая же проблема.

Проект A, на который ссылается Проект B. Проект C ссылался на Проект D, который ссылался на Проект B. Это привело к тому, что у проекта C была ссылка на проект B. Я избавился от Project D и очистил Project C (в коде), но ссылка на проект B осталась, я думаю, в виде двоичной ссылки, указывающей на папку bin проекта D.

Я обновил Проект B в визуальной студии. Когда я запустил запуск Project C, он выдал эту ошибку.

Чтобы исправить, я вошел в ссылку для Project C и удалил неиспользуемые ссылки.

Кстати, на ваш реальный вопрос - как узнать, где живет оскорбительная dll, - проще ответить так: 1. Зайдите в проводник (инструкции для окна 7 здесь) и выполните поиск по всей папке с кодом для .dll. 2. Добавьте столбец в проводнике для FileVersion и выполните сортировку по этому столбцу. Voila!

Answer 3

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

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

Answer 4

Я понимаю проблему, но я не уверен, что вы задаете правильный вопрос. Позвольте мне объяснить, как .NET выбирает ссылочную сборку.

• Ссылки сборки могут быть плавающими или закрепленными (щелкните правой кнопкой мыши сборку в папке ссылок проекта, выберите «Свойства», найдите «Конкретная версия»). Если версия плавающая, .NET найдет и использует самую последнюю версию. Имеет смысл «закрепить» версию ссылки, чтобы избежать описанных вами проблем (т. Е. Установка новой версии продукта не нарушает работу вашего приложения).

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

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

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

Answer 5

Похоже, у вас установлены обе версии Foo.dll в GAC. Проверьте gacutil , чтобы удалить старый.

Если это просто ссылка на файл, то в каждом проекте откройте «Ссылки», щелкните правой кнопкой мыши «Foo» и выберите свойства. В итоговом окне свойств вам сообщат информацию о версии.

Обычно лучший подход к таким зависимостям - это иметь отдельную папку на уровне проекта (но не часть фактического решения), называемую «Зависимости», с такими DLL-библиотеками.

Я бы также рассмотрел некоторые средства автоматизации сборки на вашем сервере (TFS = Team Build, SVN = Cruise Control и т. Д.), Которые перед сборкой скопируют правильную версию сборки в папку bin.

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