Comment puis-je tester la compatibilité ascendante de l’API entre les assemblys .net

J’ai un assemblage qui fournit une API et qui est utilisé par d’autres assemblys. Je dois vérifier qu’une version plus récente d’API dll est toujours compatible avec les anciens assemblys qui utilisaient l’ancienne version de l’API.

J’ai trouvé quelques questions qui demandent la même chose, mais aucune réponse ne résout mon problème:

Outil pour vérifier la compatibilité d’une API publique
Outil de compatibilité ascendante pour l’API C # / .NET

Les outils suggérés ne peuvent comparer que deux assemblys et indiquer s’il est possible de modifier en profondeur l’API, mais pas si la plus récente API rompt l’ancien assemblage qui l’utilise. Je voudrais trouver un outil ou écrire un test qui sera en mesure de vérifier si chacune des anciennes DLL peut fonctionner avec ma nouvelle API.

En ce qui concerne les modifications apscopes à l’API, il est plus probable que je ne l’étende que de manière étendue, mais même si cela peut toujours casser le code dans les assemblys plus anciens. Certains des exemples de tels changements peuvent être trouvés ici:

Un guide précis sur les changements révolutionnaires d’API dans .NET
.NET: en ce qui concerne AssemblyVersion, qu’est-ce qui définit la compatibilité binary?

Pour l’instant, la seule solution que je vois est de comstackr le code source des assemblys plus anciens avec la plus récente API, mais j’aimerais le faire uniquement avec des assemblys et les append dans le cadre de mes tests unitaires. Existe-t-il une meilleure façon de gérer cela?

modifier:

Je recherche un outil capable d’automatiser le processus de vérification de la compatibilité ascendante entre les assemblys .net. (ligne de commande ou avec quelques API aussi)

Ce que vous voulez, c’est faire un diff et générer une liste des changements les plus récents. Ensuite, vous souhaitez rechercher si l’un de vos assemblys utilise l’une des API cassées. Vous pouvez le faire avec l’outil ApiChange pour effectuer le diff et en rechercher les utilisateurs affectés.

Pour le rendre plus concret. Si vous avez supprimé une méthode d’une interface, vous devez rechercher tous les implémenteurs et utilisateurs de cette méthode dans des classes qui utilisent la méthode interface ou toute classe qui implémente cette méthode.

ApiChange peut rechercher des implémenteurs et des utilisateurs de méthodes spécifiques sur la ligne de commande à l’aide des commandes -whoimplementsinterface et -whousesmethod. Il n’est pas automatisé en ligne de commande, mais vous pouvez directement utiliser ApiChange.Api.dll pour automatiser ces requêtes.

Edit1:

Je viens juste d’oublier: l’outil ApiChange présente déjà les fonctionnalités qui vous intéressent. C’est l’option

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

Nous l’avons utilisé dans notre département avec de bons résultats. Les seuls fichiers obtenus sont les fichiers XML Intellisense. Si une autre cible n’utilise pas la méthode supprimée mais la référence à l’intérieur du XmlDoc, le compilateur écrira un avertissement indiquant qu’une méthode non existante a été référencée. Ceci est assez difficile à comprendre et impliquerait également d’parsingr les fichiers intellisense docu. Mais il s’agit là d’une affaire plutôt délicate.

J’ai passé la journée à chercher une réponse à cette question. Il semble que les outils référencés sur les questions connexes (inutilement fermées) soient maintenant morts ou aussi bons que. Mais je viens de jeter un coup d’œil à l’outil de assembly d’assemblage JustAssembly de Telerik et cela semble beaucoup mieux que de rouler le vôtre, qui, si vous regardez leur bibliothèque, semble être tout un travail et risque de mal tourner.

Ils ont une interface utilisateur qui n’aide pas beaucoup du sharepoint vue de l’intégration dans votre construction de CI, elle est assez basique, mais vous pouvez construire la bibliothèque à partir des sources, ce que je viens de faire et la bibliothèque y ressemble. a tout ce dont vous avez besoin pour être opérationnel assez rapidement.