Как управлять зависимостями версий в проекте C # / .NET? - PullRequest
Новая
       12

Как управлять зависимостями версий в проекте C # / .NET?

8 голосов
/ 18 ноября 2011

Предположим, у вас есть проект A, и он имеет различные зависимости dll, но дерево выглядит примерно так: 

Project A 
    => Project B
        => Project C
    => Project D
        => Project C
    => Project E
        => Project C, v2

Есть ли способ использовать Project E, поскольку он опирается на более новую версию Project C (dll), хотя остальная часть проекта использует более старую версию этой же библиотеки?

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

1 Ответ

5 голосов
/ 21 ноября 2011

Из более долгосрочного решения не уверен, будет ли это работать в вашей среде, но у нас есть несколько зависимых проектов (от фреймворков до зависимых систем), на которые мы ссылаемся. Мы используем subversion и используем внешние ссылки для ссылки на папки libary / source, чтобы все зависимые проекты ссылались на одну и ту же версию.

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

На самом деле у нас есть наш штамп процесса сборки в чем-то вроде (где _BUILD_VERSION_ заменяется процессом сборки с текущим номером сборки): 

<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
            <assemblyIdentity name="Company.DependentAssembly" publicKeyToken="8510b56c219df72e"/>
            <bindingRedirect oldVersion="1.0.0.0-99.0.0.0" newVersion="_BUILD_VERSION_"/>
        </dependentAssembly>

В той же статье также есть ссылка на несколько версий одной и той же сборки в проекте.

...