Ссылки на сборки.NET, идущие весь проспект на мне

Несоответствия в ссылках или: как я научился перестать беспокоиться и полюбить ILDASM

кхм, кашель, кашель,

Проблема

Ник,

Перечитав ваш исходный пост, становится ясно, что вы есть проблема несогласованности версии dll. То есть по крайней мере один проект в вашем решении зависит от Mcrcsip.Web версии X, и по крайней мере один проект в вашем решении зависит от Mcrcsip.Web версии Y [или, что еще хуже, зависит от библиотеки, которая зависит от Mcrcsip.Web версии Y ]. Их может быть сложно и утомительно отследить.

См. Рекомендуемое решение , чтобы перейти к концу.

Как

Такое несоответствие возникает, когда

1. у вас есть зависимость, например, A зависит от B и C, B зависит от C,
2. A и B изначально построены на C вер 1,
3. A обновлен и построен в соответствии с версией C 2,

вопреки тому, что мы интуитивно ожидаем, B не будет автоматически обновляться для использования C версии 2 при построении A. И A, и B должны ссылаться та же библиотека для правильной сборки. Таким образом, либо A должен соответствовать C вер. 1, либо B должен быть перестроен и соответствовать C вер. 2.

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

Также стоит знать, что существует два типа ссылок на зависимости, жесткие и мягкие [на самом деле, это одно и то же, то есть ссылки на библиотеки DLL, за исключением того, что один является частным случаем другого и концептуально помогает различать два].

Жесткие ссылки

Жесткие ссылки - это зависимость проекта от статической библиотеки DLL. То есть зависимость была создана в определенное время и никогда не будет обновляться, если ее физический файл не будет заменен новым. Жесткие ссылки добавляются к решению через диалоговое окно «Добавить ссылки» и добавляются ссылки из вкладок .Net, COM или «Обзор». Жесткие ссылки обычно используются для добавления зависимостей к программному обеспечению, разработанному за пределами области действия текущего решения [например, фреймворк, сторонние и другие сторонние продукты, разработанные другими внутренними группами]. Жесткие ссылки также имеют тенденцию становиться устаревшими, поскольку они поддерживаются и обновляются в собственном потоке разработки.

Предположим, что в сценарии выше

1. у вас есть зависимость, например, A зависит от B и C, B зависит от C,
2. A и B изначально построены на C версии 1,
3. A обновляется и строится на основе C вер 2,

Далее предположим, что A и B находятся в одном решении

• SimpleSolution
  • A
    • B [Жесткая ссылка]
    • C v2 [Жесткая ссылка]
  • B
    • C v1 [Жесткая ссылка]

При создании A вы получите сообщение об ошибке описано. A ожидает объект от C v2, но поскольку B имеет жесткую зависимость от C v1, C v1 сначала загружается в память, и возникает коллизия. Ожидает v2 и находит v1. Это твоя ошибка.

Чтобы разрешить эту ситуацию, вы должны

1. Обновить жесткую ссылку проекта B C v1 до C v2
2. Принудительно перестроить проект B
3. Обновить жесткую ссылку проекта A B на [недавно созданную] B
4. Принудительно перестройка A

Мягкие ссылки

Мягкая ссылка - это зависимость проекта от другого проекта в рамках того же решения. То есть зависимость перестраивается каждый раз, когда перестраивается все решение. Мягкие ссылки добавляются в решение через диалоговое окно «Добавить ссылки» и добавляются ссылки на вкладке «Проекты». Мягкие ссылки обычно используются для добавления зависимостей к программному обеспечению, разработанному в рамках текущего решения, они имеют основное преимущество распространения изменений по мере их внесения потребителям в рамках того же решения. В силу этого факта мягкие ссылки не могут быть устаревшими.

[это особый случай жесткой ссылки, Visual Studio добавит ссылку, указывающую на выходной путь целевого проекта, я считаю, что она также обновляет это path, если целевой проект изменяет свою конфигурацию вывода - но очень удобная функция, которая требует различий]

Предположим, что в сценарии выше

1. у вас есть зависимость, например, A зависит от B и C, B зависит от C,
2. A и B изначально построены для C версии 1,
3. A обновлен и построен на C версии 2,

Кроме того, предположим, что A и B находятся в одном решении

• SimpleSolution {{1} }
  • A
    • B [Мягкая ссылка]
    • C v2 [Жесткая ссылка]
  • B
    • C v1 [Жесткая ссылка]

Когда A будет собран, вы получите описанную вами ошибку.A ожидает объект от C v2, но поскольку B имеет жесткую зависимость от C v1, C v1 сначала загружается в память, и возникает коллизия. A ожидает v2 и находит v1. Это твоя ошибка.

Чтобы решить эту проблему,

1. Обновите жесткую ссылку проекта B с C v1 до C v2
2. Принудительное перестроение A

Как видите, мягкие ссылки легче поддерживать.

IL DASM [Intermediate Language DisASeMbler]

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

Самый простой способ - открыть выходной каталог сборки и проверить манифест сборки каждой библиотеки DLL, созданной вашим решением.

Чтобы проверить манифест сборки,

1. откройте ildasm.exe
   • Для VS2010 ildasm доступен по ярлыку
   • Для VS2008 и VS2005 откройте командную строку Visual Studio, в командной строке введите 'ildasm'
2. откройте dll,
   • нажмите "Файл" -> "Открыть" или
   • нажмите Ctrl-O, или
   • перетащите вашу dll в ] ildasm окно
3. открыть МАНИФЕСТ
   • дважды щелкните узел красного треугольника, помеченный МАНИФЕСТ
4. , найдите ссылки на Mcrcsip.Web
   • нажмите «Найти» и введите Mcrcsip.Web в диалоговом окне, или
   • нажмите Alt-F и введите Mcrcsip.Web в диалоговое окно, или
   • вручную проверьте содержимое файла МАНИФЕСТА
5. проверьте номер версии

Это утомительно и болезненно, но если вы столкнетесь с [нетривиальной] ошибкой несогласованности dll, это единственный способ ее найти.

Рекомендуемое решение

1. Убедитесь, что ваше решение использует мягкие ссылки, где это применимо,
   • expand Mcrcsip.Amwa.CrFactory
     • развернуть Ссылки
     • удалить ссылку Mcrcsip.Amwa.Core
     • открыть диалоговое окно «Добавить ссылки»
     • открыть Mcrcsip.Amwa.Core на вкладке «Проекты»
   • развернуть Mcrcsip.Amwa.PdfFormHandler
     • развернуть Ссылки
     • удалить ссылку Mcrcsip.Amwa.Core
     • открыть диалоговое окно «Добавить ссылки»
     • открыть Mcrcsip.Amwa.Core на вкладке «Проекты»
   • развернуть Mcrcsip.Amwa.Web {{ 1}}
     • развернуть Ссылки
     • удалить ссылку Mcrcsip.Amwa.Core
     • удалить ссылку Mcrcsip.Amwa.CrFactory
     • удалить ссылку Mcrcsip.Amwa.PdfFormHandler
     • открыть диалоговое окно «Добавить ссылки»
     • открыть Mcrcsip.Amwa.Core на вкладке «Проекты»
     • открыть Mcrcsip.Amwa.CrFactory на вкладке «Проекты»
     • открыть Mcrcsip.Amwa. PdfFormHandler из вкладки "Проекты"
2. Убедитесь, что ваше решение использует свежие жесткие ссылки, где это возможно,
   • разверните Mcrcsip.Amwa.Core
     • развернуть Ссылки
     • удалить ссылку Mcrcsip.Aws.Bol
     • удалить ссылку Mcrcsip.Common
     • удалить ссылку Mcrcsip.Web
     • открыть диалоговое окно «Добавить ссылки»
     • открыть Mcrcsip.Aws.Bol на вкладке «Обзор» [всегда лучше для указания местоположения]
     • откройте Mcrcsip.Common на вкладке «Обзор»
     • откройте Mcrcsip.Web на вкладке «Обзор»
   • разверните Mcrcsip.Amwa.CrFactory
     • разверните Ссылки
     • ] удалить ссылку Mcrcsip.Web
     • открыть диалоговое окно «Добавить ссылки»
     • открыть Mcrcsip.Web на вкладке «Обзор»
   • развернуть Mcrcsip.Amwa.PdfFormHandler
     • развернуть Ссылки
     • удалить ссылку Mcrcsip.Web
     • открыть Добавить ссылку диалоговое окно ces
     • открыть Mcrcsip.Web на вкладке «Обзор»
   • развернуть Mcrcsip.Amwa.Web
     • развернуть Ссылки
     • удалить ссылку Mcrcsip.Aws.Bol
     • удалить ссылка Mcrcsip.Common
     • удалить ссылку Mcrcsip.SharePoint
     • удалить ссылку Mcrcsip.Web
     • открыть диалоговое окно «Добавить ссылки»
     • открыть Mcrcsip.Aws.Bol на вкладке «Обзор»
     • открыть Mcrcsip.Common на вкладке «Обзор»
     • откройте Mcrcsip.SharePoint из вкладки «Обзор»
     • откройте Mcrcsip.Web из вкладки «Обзор»
3. Сборка

Если на этом этапе по-прежнему возникают ошибки, то вы знаете, что один или все из

• Mcrcsip .Aws.BOL
• Mcrcsip.Common
• Mcrcsip.SharePoint

использует вашу зависимость от Mcrcsip.Web и ссылается на старую версию. В этом случае для каждой жесткой ссылки, перечисленной выше

1. , выберите ссылку
2. нажмите F4
3. скопируйте содержимое из свойства Путь
4. диалоговое окно открытия файла в ildasm
5. вставьте в имя файла
6. проверить МАНИФЕСТ

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

Уф.

Le fin

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

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