Как я могу проверить обратную совместимость API между сборками .net - PullRequest
Новая
       26

Как я могу проверить обратную совместимость API между сборками .net

7 голосов
/ 26 ноября 2011

У меня есть сборка, которая предоставляет API и используется некоторыми другими сборками. Мне нужно убедиться, что более новая версия API DLL все еще совместима со старыми сборками, которые использовали более старую версию API.

Я нашел пару вопросов, которые задают один и тот же вопрос, но нет ответов, которые решают мою проблему:

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

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

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

редактирование:

Я ищу инструмент, который сможет автоматизировать процесс проверки обратной совместимости сборок .net. (командная строка или с некоторыми API)

Ответы [ 2 ]

10 голосов
/ 26 ноября 2011

То, что вы хотите, это сделать diff и сгенерировать список критических изменений. Затем вы хотите найти, использует ли ваша сборка какой-либо из сломанных API. Вы можете сделать это с помощью инструмента ApiChange, чтобы выполнить различие и найти любых затронутых пользователей.

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

ApiChange может искать разработчиков и пользователей определенных методов в командной строке с помощью команд -whoimplementsinterface и -whousesmethod. Он не автоматизирован в командной строке, но вы можете напрямую использовать ApiChange.Api.dll для автоматизации этих запросов.

Редактировать1:

Я просто забыл: инструмент ApiChange на самом деле обладает функциональностью , которая вас уже интересует. Это опция

-ShowrebuildTargets -new -old [-old2] -searchin

Мы использовали его в нашем отделе с хорошими результатами. Единственное, что надо - это файлы XML Intellisense. Если другая цель не использует удаленный метод, но ссылается на него внутри XmlDoc, компилятор напишет предупреждение о том, что был указан несуществующий метод. Это довольно трудно уловить, и это также потребует анализа файлов документов intellisense. Но это довольно грандиозный случай.

0 голосов
/ 28 апреля 2018

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

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

...