Ссылка на разные версии одной и той же сборки

Если A ссылается на сборку B 1.1 и C и ссылки C B 1.2, как вы избегаете конфликтов сборки?

Я предположил, что ссылки на C будут инкапсулированы и не вызовут никаких проблем, но, похоже, все DLL скопированы в bin, в которых возникает проблема.

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

Если привязки сборки не кажутся мне надежными, что, если одна версия сборки имеет функциональность, которая другая не имеет, это не вызовет проблем?

В моем случае его, потому что я использую стороннюю DLL, использует более старую версию nHibernate, чем я использую сам.

Ответ 1

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

Кроме того, вы еще не прочитали этот?

Ответ 2

По-видимому, малоизвестный способ сделать это - использовать ключевое слово extern.

Из Ссылка на С#

Чтобы ссылаться на две сборки с одинаковыми именами полностью квалифицированных типов, в командной строке должен быть указан псевдоним:

/r:GridV1=grid.dll

/r:GridV2=grid20.dll

Это создает внешние псевдонимы GridV1 и GridV2. Использовать эти алиасы из программы, ссылайтесь на них с помощью externключевое слово. Например:

extern alias GridV1;

extern alias GridV2;

Каждая декларация псевдонима extern вводит дополнительный корневой уровень пространство имен, которое параллельна (но не лежит) глобальной Пространство имен. Таким образом, типы из каждой сборки можно ссылаться без двусмысленность, используя свое полное имя, внедренное в соответствующий псевдоним пространства имен.

В предыдущем примере GridV1:: Grid будет управлять сеткой из grid.dll и GridV2:: Grid будет управлять сеткой из grid20.dll.

Ответ 3

Я должен был поддерживать несколько версий сборки и нашел это решение:

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="MyAssembly" publicKeyToken="..." />
        <codeBase version="1.1.0.0" href="MyAssembly_v1.1.0.0.dll"/>
        <codeBase version="2.0.0.0" href="MyAssembly_v2.0.0.0.dll"/>
      </dependentAssembly>
    </assemblyBinding>
  </runtime>

Ответ 4

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

<configuration>
   <runtime>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
         <dependentAssembly>
            <assemblyIdentity name="myAssembly"
                              publicKeyToken="32ab4ba45e0a69a1"
                              culture="neutral" />
            <bindingRedirect oldVersion="1.0.0.0"
                             newVersion="2.0.0.0"/>
         </dependentAssembly>
      </assemblyBinding>
   </runtime>
</configuration>

Ответ 5

Время выполнения .NET отлично способно одновременно загружать несколько версий одной и той же сборки. Однако, если вы собираетесь открывать эту банку червей, я настоятельно рекомендую вам строго указывать свои сборки и использовать схему наименования Major.Minor. *, Чтобы избежать конфликтов имен.

Я не думаю, что вам следует подумать об одном-единственном подходе к использованию (или нет) GAC. GAC может быть очень приятным, если вы хотите автоматически использовать новую функциональность, опубликованную с будущими версиями DLL. Конечно, это благословение приходит за счет того, что новые версии могут работать не так, как вы их ожидаете:). Все дело в том, что наиболее практично и насколько вы контролируете то, что публикуется в GAC.

С уважением, -Alan.