Créons un projet de plugin avec une compilation pour différentes versions de Revit / AutoCAD

Lors du développement de plugins pour des applications CAO (dans mon cas , c'est AutoCAD, Revit et Renga), un problème surgit souvent avec le temps : de nouvelles versions des logiciels sortent, leur API change et il faut créer de nouvelles versions des plugins.

Quand vous n'avez qu'un seul plugin ou si vous êtes encore un novice autodidacte dans ce domaine, il vous suffit de faire une copie du projet, de modifier les parties nécessaires et de compiler une nouvelle version du plugin. Par conséquent, toute modification ultérieure dans le code entraînera une augmentation exponentielle du temps de travail.

Au fur et à mesure que vous accumulez de l'expérience et des connaissances, vous trouverez plusieurs façons d'automatiser ce processus. J'ai parcouru ce chemin et je veux vous montrer où j'en suis arrivé et à quel point c'est pratique.

Pour commencer, examinons une méthode qui est évidente et que j'ai utilisée pendant longtemps.

Liens vers les fichiers du projet

Et pour que tout soit simple, clair et compréhensible, je vais tout décrire à partir d'un exemple abstrait de développement de plugin.

Ouvrons Visual Studio (j'ai la version Community 2019. Et oui – en français) et créons une nouvelle solution. Appelons-la MySuperPluginForRevit

Nous allons créer un plugin pour Revit pour les versions 2015-2020. Donc, je vais créer un nouveau projet dans la solution (Bibliothèque de classes .Net Framework) et l'appeler MySuperPluginForRevit_2015

Nous devons ajouter des références à l'API Revit. Bien sûr, nous pouvons ajouter des références à des fichiers locaux (il faudra installer tous les SDK nécessaires ou toutes les versions de Revit), mais nous allons directement suivre le bon chemin et connecter le paquet NuGet. Vous pouvez trouver un nombre non négligeable de paquets, mais je vais utiliser les miens.

Après avoir connecté le paquet, cliquez avec le bouton droit de la souris sur l'élément «Liens» et choisissez dans le menu l'option «Déplacer packages.config vers PackageReference…»

Si jamais à ce moment-là vous ressentez de la panique, car dans la fenêtre des propriétés du paquet il n'y a pas de point important «Copier localement», que nous devons absolument définir sur faux, ne paniquez pas – allez dans le dossier du projet, ouvrez le fichier avec l'extension .csproj dans l'éditeur de votre choix (j'utilise Notepad++) et trouvez l'entrée concernant notre paquet. Cela ressemble actuellement à ceci :

1.0.0

Ajoutons-lui la propriété runtime. Cela donnera :

1.0.0
  runtime

Désormais, lors de la création du projet, les fichiers du paquet ne seront pas copiés dans le dossier de sortie.
Continuons – imaginons d'emblée que notre plugin utilisera quelque chose de l'API Revit, qui a évolué au fil des versions. Ou simplement, nous devons modifier quelque chose dans le code en fonction de la version de Revit pour laquelle nous créons le plugin. Pour gérer ces différences de code, nous utiliserons des symboles de compilation conditionnelle. Ouvrons les propriétés du projet, allons à l'onglet «Assemblage» et dans le champ «Symboles de compilation conditionnelle» nous écrirons R2015.

Notez que le symbole doit être ajouté à la fois pour la configuration Debug et pour la configuration Release.

Et pendant que nous sommes dans la fenêtre des propriétés, passons immédiatement à l'onglet «L'application» et dans le champ «Espace de noms par défaut» supprimons le suffixe _2015, afin que notre espace de noms soit universel et indépendant du nom de l'assemblage :

Dans mon cas, tous les plugins des différentes versions sont regroupés dans un même dossier, donc mes noms d'assemblage conservent un suffixe de type _20xx. Mais vous pouvez aussi supprimer le suffixe du nom de l'assemblage si vous envisagez de placer les fichiers dans des dossiers différents.

Passons au code du fichier Class1.cs et simulons un certain code en tenant compte des différentes versions de Revit :

namespace MySuperPluginForRevit
{
    using Autodesk.Revit.Attributes;
    using Autodesk.Revit.DB;
    using Autodesk.Revit.UI;

    [Regeneration(RegenerationOption.Manual)]
    [Transaction(TransactionMode.Manual)]
    public class Class1 : IExternalCommand
    {
        public Result Execute(ExternalCommandData commandData, ref string message, ElementSet elements)
        {
#if R2015
            TaskDialog.Show("ModPlus", "Bonjour Revit 2015");
#elif R2016
            TaskDialog.Show("ModPlus", "Bonjour Revit 2016");
#elif R2017
            TaskDialog.Show("ModPlus", "Bonjour Revit 2017");
#elif R2018
            TaskDialog.Show("ModPlus", "Bonjour Revit 2018");
#elif R2019
            TaskDialog.Show("ModPlus", "Bonjour Revit 2019");
#elif R2020
            TaskDialog.Show("ModPlus", "Bonjour Revit 2020");
#endif
            return Result.Succeeded;
        }
    }
}

J'ai immédiatement pris en compte toutes les versions de Revit à partir de la version 2015 (qui étaient disponibles au moment de la rédaction de l'article) et j'ai immédiatement considéré la présence de symboles de compilation conditionnelle, qui sont créés selon le même modèle.

Passons à la pièce maîtresse. Créons un nouveau projet dans notre solution, mais cette fois pour la version du plugin pour Revit 2016. Nous répétons toutes les actions décrites ci-dessus, en remplaçant le nombre 2015 par 2016. Mais nous supprimons le fichier Class1.cs du nouveau projet.

Le fichier avec le code nécessaire – Class1.cs – est déjà disponible et nous devons simplement y faire référence dans le nouveau projet. Il y a deux méthodes pour insérer des références :

1. Longue – clic droit sur le projet, sélectionnez "Ajouter" -> "Élément existant". Dans la fenêtre qui s'ouvre, trouvez le fichier souhaité et au lieu de "Ajouter", choisissez "Ajouter comme lien»

1. Court – directement dans l'explorateur de solutions, sélectionnez le fichier (ou même les fichiers. Vous pouvez même prendre des dossiers entiers) et faites-les glisser dans le nouveau projet tout en maintenant la touche Alt enfoncée. Lorsque vous faites glisser, vous remarquerez que lorsque vous maintenez la touche Alt, le curseur changera d'un signe plus à une flèche.
   Mise à jour : J'ai semé un peu de confusion dans ce paragraphe – pour déplacer plusieurs fichiers, il faut maintenir enfoncé Maj+Alt!

Après avoir effectué cette procédure, nous aurons dans le deuxième projet un fichier Class1.cs avec l'icône correspondante (flèche bleue) :

Lors de l'édition du code dans la fenêtre de l'éditeur, vous pouvez également choisir dans le contexte de quel projet afficher le code, ce qui vous permettra de voir et d'éditer le code avec différents symboles de compilation conditionnelle :

Avec ce schéma, nous créons tous les autres projets (2017-2020). Astuce – si vous faites glisser des fichiers dans l'explorateur de solutions, pas à partir du projet de base, mais à partir du projet où ils sont déjà insérés comme liens, alors vous n'avez pas besoin de maintenir la touche Alt !

La méthode décrite est assez bonne jusqu'à ce que l'on ajoute une nouvelle version du plugin ou qu'on ajoute de nouveaux fichiers au projet – tout cela devient très fastidieux. Et récemment, j'ai soudainement réalisé comment gérer tout cela avec un seul projet, et nous passons à la deuxième méthode.

Magie des configurations

En lisant jusqu'ici, vous pourriez s'exclamer "Et pourquoi as-tu décrit la première méthode, si l'article parle directement de la seconde ?". Je l'ai fait pour clarifier pourquoi nous avons besoin de symboles de compilation conditionnelle et dans quels endroits nos projets diffèrent. Et maintenant, il nous devient plus clair quelles différences de projets nous devons réaliser, en gardant un seul projet.

Et pour que tout soit plus évident, nous ne créerons pas un nouveau projet, mais apporterons des modifications à notre projet actuel, créé de la première manière.

Tout d'abord, supprimons tous les projets de la solution, sauf le principal (qui contient directement les fichiers). C'est-à-dire les projets pour les versions 2016-2020. Ouvrons le dossier de la solution et supprimons là-bas les dossiers de ces projets.

Il ne reste qu'un projet dans la solution – MySuperPluginForRevit_2015. Ouvrons ses propriétés et :

1. Dans l'onglet "L'application", supprimons le suffixe du nom de l'assemblage _2015 (il deviendra clair par la suite pourquoi)
2. Dans l'onglet "Assemblage» supprimons le symbole de compilation conditionnelle R2015 du champ correspondant

Remarque : dans la dernière version de Visual Studio, il y a un bug – les symboles de compilation conditionnelle ne s'affichent pas dans la fenêtre des propriétés du projet, bien qu'ils soient présents. Si vous constatez ce bug, vous devrez les supprimer manuellement du fichier .csproj. Cependant, nous devons quand même travailler dedans, alors continuons.

Nous renommons le projet dans l'explorateur de solutions, en supprimant le suffixe _2015 et ensuite, nous supprimons le projet de la solution. Cela est nécessaire pour maintenir l'ordre et satisfaire les perfectionnistes ! Ouvrons le dossier de notre solution, renommons de la même manière le dossier du projet et rechargeons le projet dans la solution.

Ouvrons le gestionnaire de configurations. Nous n'aurons pas vraiment besoin de la configuration Publication donc nous la supprimons. Créons de nouvelles configurations avec les noms que nous connaissons déjà R2015, R2016, …, R2020. Notez qu'il n'est pas nécessaire de copier les paramètres d'autres configurations et qu'il n'est pas nécessaire de créer des configurations de projet :

Allons dans le dossier du projet et ouvrons le fichier avec l'extension .csproj dans l'éditeur de votre choix. D'ailleurs, il peut également être ouvert dans Visual Studio – vous devez décharger le projet, puis le point nécessaire apparaîtra dans le menu contextuel :

Il est même préférable de modifier dans Visual Studio, car l'éditeur aligne et fournit des suggestions.

Dans le fichier, nous allons voir les éléments PropertyGroup – tout en haut se trouve le groupe général, suivi de ceux avec des conditions. Ces éléments définissent les propriétés du projet lors de sa compilation. Le premier élément, sans conditions, définit les propriétés générales, tandis que les éléments avec conditions, respectivement, modifient certaines propriétés en fonction des configurations.

Passons à l'élément général (le premier) PropertyGroup et regardons la propriété AssemblyName – c'est le nom de l'assembly et il ne doit pas avoir de suffixe _2015. Si un suffixe est présent, supprimons-le.

Trouvons l'élément avec la condition

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">

Il ne nous est pas nécessaire – supprimons-le.

L'élément avec la condition

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">

sera nécessaire pour le travail lors de la phase de développement et de débogage du code. Vous pouvez modifier ses propriétés selon vos besoins – définir différents chemins de sortie, changer les symboles de compilation conditionnelle, etc.

Nous allons maintenant créer de nouveaux éléments PropertyGroup pour nos configurations. Dans ces éléments, il nous suffit de spécifier quatre propriétés :

• OutputPath – dossier de sortie. Je définis une valeur standard binR20xx
• DefineConstants – symboles de compilation conditionnelle. Il convient de définir la valeur TRACE;R20xx
• VersionDuCadreCible – version de la plateforme. Pour différentes versions de Revit API, des plateformes différentes doivent être spécifiées.
• AssemblyName – nom de l'assembly (c'est-à-dire le nom du fichier). Vous pouvez écrire directement le nom requis de l'assembly, mais pour plus d'universalité, je conseille d'écrire la valeur $(AssemblyName)_20xx. C'est pourquoi nous avons précédemment supprimé le suffixe du nom de l'assembly

La fonctionnalité la plus importante de tous ces éléments est qu'ils peuvent être facilement copiés dans d'autres projets sans même être modifiés. Plus loin dans l'article, je fournirai tout le contenu du fichier .csproj.

Bien, nous avons compris les propriétés du projet – ce n'est pas difficile. Mais que faire avec les bibliothèques connectées (paquetages NuGet). Si nous regardons plus loin, nous verrons que les bibliothèques connectées sont spécifiées dans les éléments ItemGroup. Mais voici le problème – cet élément traite incorrectement les conditions, comme l'élément PropertyGroup. Cela pourrait même être un bug de Visual Studio, mais si l'on définit plusieurs éléments ItemGroup avec des conditions de configuration, et qu'à l'intérieur on insère différents liens vers des paquetages NuGet, alors lors du changement de configuration, tous les paquetages spécifiés sont ajoutés au projet.

L'élément Choose, qui fonctionne selon la logique qui nous est familière, nous aide. if-then-else.

En utilisant l'élément Choose, nous spécifions différents paquetages NuGet pour différentes configurations :

Tout le contenu de csproj

Debug
    AnyCPU
    {5AD738D6-4122-4E76-B865-BE7CE0F6B3EB}
    Library
    Properties
    MySuperPluginForRevit
    MySuperPluginForRevit
    v4.5
    512
    true
  
  
    true
    full
    false
    binDebug
    DEBUG;R2015
    prompt
    4
  
  
    binR2015
    TRACE;R2015
    v4.5
    $(AssemblyName)_2015
  
  
    binR2016
    TRACE;R2016
    v4.5
    $(AssemblyName)_2016
  
  
    binR2017
    TRACE;R2017
    v4.5.2
    $(AssemblyName)_2017
  
  
    binR2018
    TRACE;R2018
    v4.5.2
    $(AssemblyName)_2018
  
  
    binR2019
    TRACE;R2019
    v4.7
    $(AssemblyName)_2019
  
  
    binR2020
    TRACE;R2020
    v4.7
    $(AssemblyName)_2020
  
  
    
    
    
    
    
    
    
    
  
  
    
    
  
  
    
      
        
          1.0.0
          runtime
        
      
    
    
      
        
          1.0.0
          runtime
        
      
    
    
      
        
          1.0.0
          runtime
        
      
    
    
      
        
          1.0.0
          runtime
        
      
    
    
      
        
          1.0.0
          runtime
        
      
    
    
      
        
          1.0.0
          runtime

Veuillez noter qu'une de mes conditions stipule que deux configurations sont indiquées par OU (Or). Ainsi, le bon paquet sera connecté lors de la configuration Débogage.

Et nous avons presque tout de parfait. Nous rechargeons le projet, activons la configuration dont nous avons besoin, puis dans le menu contextuel de la solution (pas du projet) nous sélectionnons l'option «Restaurer tous les paquets NuGet» et nous voyons comment nos paquets changent.

Et à ce stade, je suis arrivé à une impasse - pour construire toutes les configurations en même temps, nous pourrions utiliser la construction par lots (menu «Assemblage" -> "Construction par lots»), mais le changement de configurations ne déclenche pas automatiquement la restauration des paquets. Et lors de la construction du projet, cela ne se produit pas non plus, bien que cela devrait théoriquement. Je n'ai pas trouvé de solution à ce problème avec les moyens standards. Et il y a fort à parier que c'est aussi un bug de Visual Studio.

Donc, pour la construction par lots, il a été décidé d'utiliser un système de construction automatisée Nuke. En réalité, je ne voulais pas faire cela, car je pense que c'est superflu dans le cadre du développement de plugins, mais à l'heure actuelle, je ne vois pas d'autre solution. Quant à la question «Pourquoi Nuke ?», la réponse est simple : nous l'utilisons au travail.

Donc, nous allons dans le dossier de notre solution (pas du projet), nous maintenons la touche Shift et faisons un clic droit dans un espace vide du dossier - dans le menu contextuel, nous choisissons l'option «Ouvrir PowerShell ici».

Si vous n'avez pas installé nuke, commencez par écrire la commande

dotnet tool install Nuke.GlobalTool –global

Ensuite, écrivez la commande nuke et il vous sera proposé de configurer nuke pour le projet actuel. Je ne sais pas comment cela serait mieux formulé en russe - en anglais, il sera écrit Could not find .nuke file. Do you want to setup a build? [y/n]

Appuyez sur la touche Y et ensuite il y aura les étapes de configuration propres. Nous avons besoin de l'option la plus simple en utilisant MSBuild, donc nous répondons comme sur la capture d'écran :

Passons à Visual Studio, qui nous proposera de recharger la solution, car un nouveau projet a été ajouté. Nous rechargeons la solution et voyons qu'un projet est apparu build dans lequel nous ne sommes intéressés que par un fichier - Build.cs

Nous ouvrons ce fichier et écrivons le script de construction du projet pour toutes les configurations. Ou nous utilisons mon script, que vous pouvez modifier selon vos besoins :

using System.IO;
using Nuke.Common;
using Nuke.Common.Execution;
using Nuke.Common.ProjectModel;
using Nuke.Common.Tools.MSBuild;
using static Nuke.Common.Tools.MSBuild.MSBuildTasks;

[CheckBuildProjectConfigurations]
[UnsetVisualStudioEnvironmentVariables]
class Build : NukeBuild
{
    public static int Main () => Execute<Build>(x => x.Compile);

    [Solution] readonly Solution Solution;

    // Si le nom de la solution et le nom du projet (plugin) sont différents, indiquez le nom du projet (plugin) ici
    string PluginName => Solution.Name;

    Target Compile => _ => _
        .Executes(() =>
        {
            var project = Solution.GetProject(PluginName);
            if (project == null)
                throw new FileNotFoundException("Non trouvé!");

            var build = new List<string>();
            foreach (var (_, c) in project.Configurations)
            {
                var configuration = c.Split("|")[0];

                if (configuration == "Debug" || build.Contains(configuration))
                    continue;

                Logger.Normal($"Configuration : {configuration}");

                build.Add(configuration);

                MSBuild(_ => _
                    .SetProjectFile(project.Path)
                    .SetConfiguration(configuration)
                    .SetTargets("Restore"));
                MSBuild(_ => _
                    .SetProjectFile(project.Path)
                    .SetConfiguration(configuration)
                    .SetTargets("Rebuild"));
            }
        });
}

Nous retournons à la fenêtre PowerShell et réécrivons la commande nuke (vous pouvez écrire la commande nuke en spécifiant le nécessaire Cible. Mais nous en avons un Cible, qui s'exécute par défaut). Après avoir appuyé sur la touche Entrée, nous nous sentirons comme de véritables hackers, car, comme dans les films, la compilation automatique de notre projet pour différentes configurations se produira.

Au fait, vous pouvez utiliser PowerShell directement depuis Visual Studio (menu «Affichage" -> "Autres fenêtres" -> "Console du gestionnaire de packages»), mais tout sera en noir et blanc, ce qui n'est pas très pratique.

Ainsi se termine mon article. Je suis sûr qu'avec l'option pour AutoCAD, vous pourrez vous débrouiller vous-mêmes. J'espère que le matériel présenté ici trouvera ses "clients".

Merci de votre attention !

Source : habr.com