Създаваме проект на плъгин с компилация за различни версии на Revit/AutoCAD

При разработването на плъгини за CAD приложения (в моя случай това са AutoCAD, Revit и Renga) с времето се появява един проблем – излизат нови версии на програмите, променя се техният API и трябва да се правят нови версии на плъгините.

Когато имате само един плъгин или сте новак в това, можете просто да направите копие на проекта, да промените необходимите места в него и да съберете нова версия на плъгина. Съответно, последващите промени в кода ще доведат до многократно увеличаване на трудоемкостта.

С натрупването на опит и знания ще намерите няколко начина за автоматизация на този процес. Аз съм преминал по този път и искам да споделя с вас до какво съм стигнал в крайна сметка и колко удобно е.

Първо, нека разгледаме метод, който е очевиден и който дълго време използвах.

Връзки към файловете на проекта

И за да е всичко просто, нагледно и разбираемо, ще опиша всичко на абстрактен пример при разработването на плъгин.

Отваряме Visual Studio (аз имам версия Community 2019. И да – на руски) и създаваме ново решение. Нека го наречем MySuperPluginForRevit

Ще правим плъгин за Revit за версиите 2015-2020. Затова ще създам нов проект в решението (Библиотека класове .Net Framework) и ще го наречем MySuperPluginForRevit_2015

Трябва да добавим връзки към API на Revit. Разбира се, можем да добавим връзки към локални файлове (трябва да инсталираме всичките необходими SDK или всички версии на Revit), но ние ще поемем по правилния път и ще свържем пакета NuGet. Можете да намерите немалко количество пакети, но ще използвам собствените си.

След свързването на пакета кликнете с десния бутон върху елемента «Връзки» и изберете в менюто «Прехвърли packages.config в PackageReference…»

Ако изведнъж тук ви завладее паника, тъй като в прозореца на свойствата на пакета няма важния елемент «Копирай локално», който задължително трябва да се зададе на стойност неверно, не се паникьосвайте – отиваме в папката с проекта, отваряме файла с разширение .csproj в удобен за вас редактор (аз използвам Notepad++) и намираме записа за нашия пакет. В момента изглежда така:

1.0.0

Добавяме му свойството runtime. Получава се така:

1.0.0
  runtime

Сега, когато изграждаме проекта, файловете от пакета няма да се копират в изходната папка.
Продължаваме – веднага ще представим, че нашият плъгин ще използва нещо от Revit API, което се е променяло с времето при излизането на нови версии. Или просто трябва да променим нещо в кода в зависимост от версията на Revit, за която правим плъгина. За решаване на такива разлики в кода ще използваме символи за условна компилация. Ще отворим свойствата на проекта, ще преминем на таба „Сборка“ и в полето „Дефиниции за условна компилация“ ще напишем R2015.

Обърнете внимание, че символът трябва да се добави и за конфигурация Debug и за конфигурация Release.

Докато сме в прозореца със свойствата, ще преминем на таба „Приложение“ и в полето „Основно пространство от имена“ и ще премахнем суфикса _2015, за да бъде нашето пространство от имена универсално и независимо от името на сборката:

В моя случай в крайния продукт плъгините на всички версии се съхраняват в една папка, така че имената на сборките ми остават с суфикс от вида _20хх. Но можете да премахнете суфикса и от името на сборката, ако се предполага, че файловете ще бъдат разположени в различни папки.

Преминаваме към кода на файла Class1.cs и имитираме там определен код с оглед на различните версии на 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", "Здравей, Revit 2015");
#elif R2016
            TaskDialog.Show("ModPlus", "Здравей, Revit 2016");
#elif R2017
            TaskDialog.Show("ModPlus", "Здравей, Revit 2017");
#elif R2018
            TaskDialog.Show("ModPlus", "Здравей, Revit 2018");
#elif R2019
            TaskDialog.Show("ModPlus", "Здравей, Revit 2019");
#elif R2020
            TaskDialog.Show("ModPlus", "Здравей, Revit 2020");
#endif
            return Result.Succeeded;
        }
    }
}

Веднага взех предвид всички версии на Revit, по-горе от версия 2015 (които бяха налични по времето на писането на статията) и веднага взех предвид наличието на символи за условна компилация, които се създават по един и същи шаблон.

Преминаваме към основната изненада. Създаваме нов проект в нашето решение, само че за версията на плъгина под Revit 2016. Повтаряме всичките описани по-горе действия, като съответно заменяме числото 2015 с 2016. Но файлът Class1.cs от новия проект изтриваме.

Файлът с необходимия код – Class1.cs – вече го имаме и просто трябва да поставим линк към него в новия проект. Има два начина за вмъкване на линкове:

1. Дълъг – натискаме с десния бутон на проекта и избираме опцията «Добави» -> «Съществуващ елемент», в отвореното прозорче намираме нужния файл и вместо опцията «Добави» избираме опцията «Добави като връзка»

1. Кратък – директно в решавача на проекти избираме нужния файл (или файлове, или дори цели папки) и ги плъзгаме в новия проект, задържайки клавиша Alt. При плъзгането ще видите, че курсорът на мишката ще сменя формата си от плюсче на стрелка, когато задържате клавиша Alt.
   UPD: Някак си внесох объркване в този параграф – за да премествате няколко файла, трябва да задържате Shift+Alt!

След приключване на процедурата в нашия втори проект ще се появи файл Class1.cs с съответната иконка (синя стрелка):

При редактиране на кода в редактора можете също да избирате в контекста на кой проект да се показва кода, което ще ви позволи да видите и редактирате кода при различни символи на условна компилация:

По тази схема създаваме всички останали проекти (2017-2020). Лайфхак – ако плъзгате файлове в решавача на проекти не от основния проект, а от проект, където те вече са добавени като връзка, можете да не задържате клавиша Alt!

Описаният вариант е напълно добър, докато не добавите нова версия на плъгина или нови файлове в проекта – всичко това става доста досадно. А наскоро изведнъж осъзнах как всичко това да се реши с един проект и преминаваме към втория метод.

Магия на конфигурациите

След като стигнете до тук, може да извикате «Защо описваш първия метод, ако статията е веднага за втория?!». Описах всичко, за да е по-ясно за какво са ни нужни символите на условната компилация и в какви места имаме различия в проектите. И сега ни става по-ясно какви именно разлики в проектите трябва да реализираме, оставяйки само един проект.

И за да е всичко по-очевидно, няма да създаваме нов проект, а ще направим промени в текущия проект, създаден по първия метод.

И така, на първо място, изтриваме от решението всички проекти, освен основния (съдържащ директно файловете). Т.е. проектите за версиите 2016-2020. Отваряме папката с решението и изтриваме папките на тези проекти.

В нашето решение остава само един проект — MySuperPluginForRevit_2015. Отваряме неговите свойства и:

1. На таба «Приложение» от името на компилацията изтриваме суфиксът _2015 (по-нататък ще стане ясно защо)
2. На таба «Сборка» премахваме символа на условна компилация R2015 от съответното поле

Забележка: в последната версия на Visual Studio има бъг – символите на условна компилация не се показват в прозореца със свойства на проекта, макар че са налични. Ако наблюдавате този бъг, ще трябва да ги премахнете ръчно от файла .csproj. Въпреки това, все още ще работим в него, така че продължаваме.

Преименуваме проекта в прозореца на решението, като премахнем суфиксa _2015 и след това премахваме проекта от решението. Това е необходимо за поддържане на ред и чувството на перфекционизъм! Отваряме папката на нашето решение, преименуваме там по същия начин папката на проекта и зареждаме проекта обратно в решението.

Отваряме диспетчера на конфигурации. Конфигурацията Release в принципе не ни е необходима, затова я премахваме. Създаваме нови конфигурации с вече познатите ни имена R2015, R2016, …, R2020. Обърнете внимание, че не е нужно да копирате параметри от други конфигурации и не е нужно да създавате конфигурации на проекта:

Отиваме в папката с проекта и отваряме файла с разширение .csproj в удобен за вас редактор. Действително, можете да го отворите и в Visual Studio – трябва да изключите проекта, след което в контекстното меню ще бъде необходимата опция:

Редактиране в Visual Studio е даже предпочитано, тъй като редакторът подравнява и подскаже.

В файла ще видим елементи PropertyGroup – в самия връх е общият, следван от тези с условия. Тези елементи задават свойства на проекта при неговото компилиране. Първият елемент, който няма условия, задава общите свойства, а елементите с условия, съответно, променят някои свойства в зависимост от конфигурациите.

Преминаваме към общия (първи) елемент PropertyGroup и гледаме свойството AssemblyName – това е името на сборката и то не трябва да има суфикс _2015. Ако суфиксът е наличен, го премахваме.

Намираме елемента с условие

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

Той не ни е нужен – премахваме го.

Елементът с условие

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

ще е необходим за работа по време на етапа на разработка и отстраняване на грешки. Можете да променяте свойствата му според нуждите си – да задавате различни изходни пътища, да променяте символите на условна компилация и т.н.

Сега създаваме нови елементи PropertyGroup за нашите конфигурации. В тези елементи ни е достатъчно да зададем четири свойства:

• OutputPath – изходната папка. Аз задавам стандартната стойност binR20xx
• DefineConstants – символи за условна компилация. Трябва да зададете стойност TRACE;R20хх
• TargetFrameworkVersion – версия на платформата. За различни версии на Revit API трябва да зададете различни платформи.
• AssemblyName – име на сборката (т.е. името на файла). Можете да напишете директно името на сборката, но за универсалност съветвам да напишете стойността $(AssemblyName)_20хх. За целта ние преди това премахнахме суфикса от името на сборката

Най-важната характеристика на всички тези елементи – те могат просто да бъдат копирани в други проекти, без да се променят. По-долу в статията ще приложа съдържанието на файла .csproj.

Добре, с проектните свойства разбрахме – това не е сложно. Но какво да правим с добавените библиотеки (NuGet пакети). Ако погледнем по-нататък, ще видим, че добавените библиотеки се задават в елементите ItemGroup. Но ето едно недоразумение – този елемент обработва условията неправилно, като елемент PropertyGroup. Възможно е това да е дори бъг на Visual Studio, но ако зададете няколко елемента ItemGroup с условията на конфигурациите, а вътре поставите различни връзки към NuGet пакети, то при смяна на конфигурацията към проекта се добавят всички посочени пакети.

На помощ ни идва елементът Изберете, който работи по познатата ни логика if-then-else.

Използвайки елемента Изберете, задаваме различни NuGet пакети за различни конфигурации:

Всичкото съдържание 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

Обърнете внимание, че в едно от условията посочих две конфигурации чрез ИЛИ (Or). Така ще се свързва необходимият пакет при конфигурация Debug.

И ето че почти всичко е идеално. Зареждаме обратно проекта, включваме необходимата конфигурация, извикваме от контекстното меню на решението (не на проекта) пункта „Възстановяване на всички пакети NuGet“ и виждаме как се променят пакета ни.

И на този етап стигнах до задънена улица – за да съберем веднага всички конфигурации, можехме да се възползваме от пакетното изграждане (меню „Сборка» -> «Пакетно изграждане“), но при смяната на конфигурациите няма автоматично възстановяване на пакети. И при изграждането на проекта също не се случва, въпреки че по идея би трябвало. Решение на този проблем с стандартни средства не намерих. И вероятно това също е бъг на Visual Studio.

Затова за пакетно изграждане решихме да използваме специализирана система за автоматизирано изграждане Nuke. Всъщност не исках да го правя, тъй като смятам, че е излишно в рамките на разработването на плъгини, но в момента не виждам друго решение. А на въпроса „Защо именно Nuke?“ отговорът е прост – използваме го на работа.

И така, отиваме в папката на нашето решение (не на проекта), задържаме клавиша Shift и щракваме с десния бутон на мишката върху празното място в папката – в контекстното меню избираме пункта „Отвори PowerShell тук».

Ако нямате инсталиран nuke, първо напишете командата

dotnet tool install Nuke.GlobalTool –global

Сега напишете командата nuke и ще се предложи да настроите nuke за текущия проект. Не знам как е по-правилно да се напише на български – на английски ще се напише Could not find .nuke file. Do you want to setup a build? [y/n]

Натискаме клавиша Y и след това ще имаме непосредствени точки за настройка. Нужен ни е най-простият вариант с използване на MSBuild, затова отговаряме както на екрана:

Прехвърляме се в Visual Studio, която ще предложи да презаредим решението, тъй като в него е добавен нов проект. Презареждаме решението и виждаме, че се е появил проект build , в който ни интересува само един файл – Build.cs

Отваряме този файл и пишем скрипт за изграждане на проекта под всички конфигурации. Или използваме моя скрипт, който можете да редактирате за себе си:

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(x => x.Compile);

    [Solution] readonly Solution Solution;

    // If the solution name and the project (plugin) name are different, then indicate the project (plugin) name here
    string PluginName => Solution.Name;

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

            var build = new List();
            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"));
            }
        });
}

Връщаме се в прозореца на PowerShell и отново пишем командата nuke (можете да напишете командата nuke с указание на необходимото Цел. Но имаме един Цел, който се изпълнява по подразбиране). След натискане на клавиша Enter, ще се почувстваме като истински хакери, тъй като автоматичната компилация на нашия проект за различни конфигурации ще се случи, точно както във филмите.

Между другото, можете да използвате PowerShell директно от Visual Studio (менюто „Изглед» -> «Други прозорци» -> «Конзола на пакетния мениджър“), но там всичко ще е черно-бяло, което не е много удобно.

На това приключвам моята статия. Уверен съм, че ще можете сами да се справите с версията за AutoCAD. Надявам се, че материалът, изложен тук, ще намери своите „клиенти“.

Благодаря за вниманието!

Източник: habr.com