Teeme ühe pistiku projekti erinevate Revit / AutoCAD versioonide all kompileerimisega

CAD rakenduste pluginite arendamisel (minu puhul on see AutoCAD, Revit ja Renga) tekib ajaga üks probleem – ilmuvad uued tarkvara versioonid, nende API muutub ja tuleb teha uued pluginite versioonid.

Kui teil on ainult üks plugin või olete alles algaja, siis saate lihtsalt projekti koopia teha, muuta seal vajalikud kohad ja luua uue pluginiversiooni. Vastavalt sellele toob koodi edasine muutmine kaasa tööjõu vajaduse kordse suurenemise.

Kogemuste ja teadmiste kasvades leiate mitmeid viise selle protsessi automatiseerimiseks. Olen selle tee käinud ja tahan jagada teiega, kuhu ma lõpuks jõudsin ja kui mugav see on.

Alustame ilmse meetodi arutamisega, mida olen pikka aega kasutanud.

Viidatud projekti failidele

Ja et kõik oleks lihtne, selge ja arusaadav, kirjeldan kõike abstraktsel näitel pluginite arendamisest.

Avame Visual Studio (mul on Community 2019 versioon. Ja jah – vene keeles) ja loome uue lahenduse. Nimeks anname MySuperPluginForRevit

Loome plugin Revitile versioonide 2015-2020 jaoks. Seetõttu loon lahenduses uue projekti (Net Frameworki klasside teek) ja nimetan selle MySuperPluginForRevit_2015

Peame lisama viidatud Revit API-le. Muidugi saame lisada viidatud kohalikud failid (tuleb endale kõik vajalikud SDK-d või kõik versioonid Revitist installeerida), kuid me läheme kohe õigele teele ja lisame NuGet paketi. Te leiate üsna palju pakette, kuid ma kasutan omaenda.

Pärast paketi ühendamist klõpsame parema hiireklahviga punktile „Viidatud lingidja valime menüüst „Edastada packages.config PackageReference’iks…»

Kui teil peaks selle koha pealt paanikahoog tulema, kuna paketi omaduste aknas ei ole olulist punkti „Kopeeri kohalikultmistõttu peame selle kindlasti seadistama väärtuseks false, siis ei maksa paanitseda – läheme projekti kausta, avame .csproj laiendiga faili sobivas redaktoris (mina kasutan Notepad++) ja otsime seal üles meie paketi kirje. See näeb praegu välja nii:

1.0.0

Lisame sellele omaduse runtime. Tulemus saab olema järgmine:

1.0.0
  runtime

Nüüd, kui projekt on loodud, ei koondata paketi faile väljundkausta.
Liigume edasi – eeldame kohe, et meie plugin kasutab midagi Revit API-st, mis on ajas muutunud, kui on välja antud uusi versioone. Või lihtsalt on meil vaja midagi oma koodis muuta sõltuvalt Revit'i versioonist, mille jaoks me pluginit teeme. Nende koodide erinevuste lahendamiseks kasutame tingimusliku kompileerimise sümboleid. Avame projekti omadused, liigume sakkidele „Kogumine„ ja väljal „Tingimusliku kompileerimise sümbolid„ kirjutame R2015.

Pange tähele, et sümbol tuleb lisada nii Debug konfiguratsiooni kui ka Release konfiguratsiooni jaoks.

Ja kuna me oleme omaduste aknas, läheme kohe sakkide „Rakendus„ ja väljal „Vaikimisi nimed„ alla ja eemaldame sufiksi _2015, et meie nimi oleks universaalne ja sõltumatu kogumi nimest:

Minu puhul ladustatakse kõigi versioonide pluginaid lõppproduktis ühte kausta, seega jäävad mu kogumi nimed sufiksiga _20xx. Kuid võite eemaldada sufiksi ka kogumi nimest, kui failide asukohti eeldatakse erinevates kaustes.

Liigume faili koodi Class1.cs ja simuleerime seal mingit koodi, arvestades erinevaid Revit'i versioone:

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", "Tere Revit 2015");
#elif R2016
            TaskDialog.Show("ModPlus", "Tere Revit 2016");
#elif R2017
            TaskDialog.Show("ModPlus", "Tere Revit 2017");
#elif R2018
            TaskDialog.Show("ModPlus", "Tere Revit 2018");
#elif R2019
            TaskDialog.Show("ModPlus", "Tere Revit 2019");
#elif R2020
            TaskDialog.Show("ModPlus", "Tere Revit 2020");
#endif
            return Result.Succeeded;
        }
    }
}

Olin kohe arvestanud kõiki Revit'i versioone alates 2015. aastast (millel oli artikkel kirjutamise ajal) ja kohe arvestanud tingimusliku kompileerimise sümbolite olemasolu, mis luuakse mulle sama malli järgi.

Liigume peamise ilu juurde. Loome oma lahendusse uue projekti, ainult Revit 2016 pluginiversioonile. Korrame kõik ülaltoodud toimingud, asendades numbreid 2015 numbriga 2016. Kuid faili Class1.cs uusest projektist kustutame.

Fail, kus on vajalik kood – Class1.cs – meil juba olemas ja meil on vaja lihtsalt sellele uues projektis link lisada. Linkide lisamiseks on kaks teed:

1. Pikk – parem puudutame projekti paremast hiireklahvist, valime punktilt «Lisa» -> «Olemasolev element», avatud aknas leiame vajaliku faili ja valime variandi «Lisa» asemel valime variandi «Lisa seoseks»

1. Lühike – otse lahenduse sirvijas valime vajaliku faili (või isegi faile. Võime isegi terveid kaustu) ja lohistame uude projektisse, hoides all klahvi Alt. Loome tõmmates näete, et alt klahvi all hoides muutub hiirekursor plussmärkidest nooleks.
   UPD: Ma tegin selle lõiguga veidi segadust — et lohistada mitu faili, tuleb hoida all Shift+Alt!

Pärast protseduuri toimub meil teises projektis fail Class1.cs vastava ikooniga (sinine nool):

Koodi redigeerimisel redigeerimisaknas saate samuti valida, millise projekti kontekstis koodi kuvada, mis võimaldab teil näha, kuidas kood erinevate tingimuslike kompileerimise märkide abil redigeeritakse:

Selle skeemi järgi loome kõik ülejäänud projektid (2017-2020). Elu näpunäide – kui lohistada faile lahenduse sirvijas mitte baasprojektist, vaid projektist, kus need on juba ühendatud, siis ei pea alt klahvi all hoidma!

Kirjeldatud variant on üsna hea kuni hetkeni, mil lisatakse uus pluginaversioon või lisatakse projekti uusi faile – kõik see muutub väga tüütu. Ja hiljuti taipasin ma äkki, kuidas seda ühe projektiga lahendada ja liigume teise meetodi juurde.

Konfiguratsioonide maagia

Siia lugedes võite exclaimida «Miks sa esimest meetodit kirjeldasid, kui artikkel on kohe teise kohta?!». Kirjutasin ma kõik selleks, et oleks selgem, mille jaoks me vajame tingimuslikke kompileerimise sümboleid ja millistes kohtades erinevad meie projektid. Ja nüüd on meil selgem, millised erinevused projektide vahel peame ellu viima, jättes ainult ühe projekti.

Ja et kõik oleks selgem, me ei loo uut projekti, vaid teeme muudatusi meie praeguses projektis, mis loodi esimesel meetodil.

Nii et, kõigepealt eemaldame lahendusest kõik projektid, välja arvatud põhiprojekt (millel on otseselt failid). T. e. projektid versioonide 2016-2020 jaoks. Avame kausta lahenduse ja eemaldame seal nende projektide kaustad.

Meil on lahenduses alles jäänud üks projekt — MySuperPluginForRevit_2015. Avame selle omadused ja:

1. Vahekaardil «Rakendus» eemaldame kogumi nimest sufiksi _2015 (edasi saate aru, miks)
2. Vahekaardil «Kogumine» eemaldame tingimusliku kompileerimise sümboli R2015 to corresponding field

Märkus: viimasest Visual Studio versioonist leiti viga – tingimuslikud kompileerimise sümbolid ei kuvata projekti omaduste aknas, kuigi need on olemas. Kui teil on see tõrge, peate need käsitsi .csproj failist eemaldama. Kuid me peame sellega edasi töötama, seega loeme edasi.

Nimega projekt lahenduse sirvija aknas, kustutame sufiksi _2015 ja seejärel eemaldame projekti lahendusest. See on vajalik korra säilitamiseks ja perfektsionistide tundete jaoks! Avame meie lahenduse kausta, nimetame seal sama moodi projekti kausta ümber ja laadime projekti tagasi lahendusse.

Avame konfiguratsioonihalduri. Meil on konfiguratsioon Release tõeliselt ei ole seda vaja, seega eemaldame selle. Loome uusi konfiguratsioone, mille nimed on meile juba tuttavad R2015, R2016, …, R2020. Pange tähele, et parameter ei pea olema teistest konfiguratsioonidest kopeeritud ja projekti konfiguratsioone looma ei pea:

Läheme projekti kausta ja avame .csproj laiendiga faili endale sobivas redigeerijas. Üksikasjalikult, seda saab avada ka Visual Studios - projekti tuleb laadida välja ja seejärel otsige kontekstimenüüst vajalik valik:

Redigeerimine Visual Studios on isegi eelistatum, kuna redigeerija tasandab ja annab vihjeid.

Failis näeme elemente PropertyGroup – kõige peal on üldine, ja seejärel tingimustega. Need elemendid määravad projekti omadused selle ühiselt. Esimene element, mis tingimusteta, määrab üldised omadused, ja tingimustega elemendid muudavad vastavalt mõned omadused konfiguratsioonide põhjal.

Liigume esimese ühise elemendi juurde PropertyGroup ja vaatame omadust AssemblyName – see on kogumise nimi ja see peaks olema ilma sufiksita _2015. Kui sufiks on olemas, eemaldame selle.

Leidke tingimusega element

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

See ei ole meile vajalik – eemaldame selle.

Tingimusega element

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

on vajalik koodi arendamise ja silumise etapi tööks. Saate muuta selle omadusi vastavalt oma vajadustele – määrata erinevad väljundteed, muuta tingimuslikud kompileerimise sümbolid jne.

Nüüd loome uusi elemente PropertyGroup oma konfiguratsioonide jaoks. Nendes elementides on meil piisav määrata neli omadust:

• OutputPath – väljundkaust. Määran standardväärtuse binR20xx
• DefineConstants – tingimisi kompileerimise sümbolid. Tuleb määrata väärtus TRACE;R20xx
• TargetFrameworkVersion – platvormi versioon. Erinevate Revit API versioonide jaoks peab määrama erinevad platvormid.
• AssemblyName – kogumi nimi (st. faili nimi). Saate kirjutada otse vajaliku kogumi nime, kuid universaalsuse huvides soovitan määrata väärtuse $(AssemblyName)_20xx. Selleks eemaldasime varem kogumi nimest sufiksi

Kõige olulisem feature nende elementide seas on see, et neid saab lihtsalt kopeerida teistesse projektidesse, muutes need täiesti muutumatuks. Edasi artiklis lisan kogu .csproj faili sisu.

Nii, projektide omadustega oleme selgelt toime tulnud – see pole keeruline. Kuid mida teha ühendatud raamatukogudega (NuGet-pakettidega). Kui vaadata edasi, näeme, et ühendatud raamatukogud määratakse elementidesse ItemGroup. Kuid here on probleem – see element käsitleb tingimusi valesti, nagu element PropertyGroup. Võib-olla on see isegi Visual Studio viga, kuid kui määrata mitu elementi ItemGroup koos konfiguratsiooni tingimustega ja sisestada erinevad viidatud NuGet-pakettide lingid, siis konfiguratsiooni muutmisel lisatakse projekti kõik määratud paketid.

Meie abiks tuleb element Vali, mis töötab tuttava loogika järgi if-then-else.

Kasutades elementi Vali, määrame erinevad NuGet-paketid erinevatele konfiguratsioonidele:

Kogu csproj sisu

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

Pange tähele, et ühes tingimuses olen ma märkinud kaks konfiguratsiooni läbi VÕI (Or). Seega ühendatakse vajalik pakett konfiguratsiooni seadistamisel Debug.

Ja nüüd on meil peaaegu kõik ideaalselt. Laadime projekti tagasi, aktiveerime vajalikku konfiguratsiooni, valime lahenduse (mitte projekti) kontekstimenüüst punkti «Taasta kõik NuGet paketid» ja näeme, kuidas meie paketid muutuvad.

Ja nüüd olen selle etappi jõudnud ummikusse – et koguda kohe kõik konfiguratsioonid, saaksime kasutada pakettide kogumist (menüüd «Kogumine» -> «Pakettide kogumine»), kuid konfiguratsioonide vahetamisel ei toimu automaatset pakettide taastamist. Ja projekti ehitamisel samuti mitte, kuigi peaks. Selle probleemi lahenduste standardsete vahenditega ma ei leidnud. Ja tõenäoliselt on see samuti Visual Studio viga.

Seetõttu otsustati pakettide kogumise jaoks kasutada spetsiaalset automatiseeritud kogumise süsteemi Nuke. Tegelikult ma seda ei tahtnud, kuna pean seda liialdusena pistikprogrammide arendamise raames, kuid praegu ei näe ma muud lahendust. Ja küsimusele «Miks just Nuke?» on vastus lihtne – kasutame tööl.

Nii et liigume lahenduse kausta (mitte projekti), hoidke all klahvi Shift ja klõpsake hiire parema nupuga kaustas tühjal kohal – kontekstimenüüst valige punkt «Ava PowerShell aken siin».

Kui teil ei ole installitud nuke, siis kirjutage esmalt käsk

dotnet tool install Nuke.GlobalTool –global

Nüüd kirjutage käsk nuke ja teile pakutakse seadistada nuke praeguse projekti jaoks. Ma ei tea, kuidas seda õigemini eesti keeles kirjutada – inglise keeles oleks kirjutatud Could not find .nuke file. Do you want to setup a build? [y/n]

Vajutame klahvi Y ja edasi tuleb vahetud seadistamise punktid. Meil on vaja kõige lihtsamat varianti kasutades MSBuild, seega vastame nagu ekraanipildil:

Liigume Visual Studio'sse, mis pakub meile lahenduse uuesti laadimist, kuna see on lisatud uus projekt. Laadime lahenduse uuesti ja näeme, et meil on ilmunud projekt build milles meil huvitab ainult üks fail – Build.cs

Avame selle faili ja kirjutame skripti projekti kogumiseks kõigi konfiguratsioonide jaoks. Või kasutame minu skripti, mida saate endale kohandada:

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"));
            }
        });
}

Naasime PowerShelli akn ja jälle kirjuta käsku nuke (käsku saab kirjutada nuke vajalikku märkustusega Täht. Aga meil on üks Täht, mis käivitub vaikimisi). Pärast Enteri vajutamist tunneme end tõeliste häkkeritena, kuna nagu filmides toimetatakse meie projekti automaatne koostamine erinevate konfiguratsioonide all.

Muide, PowerShelli saab kasutada otse Visual Studios (menüüs „Vaade» -> «Teised aknad» -> «Pakettide halduri konsool“), kuid seal on kõik must-valge, mis pole just mugav.

Sellega minu artikkel lõppeb. Olen kindel, et AutoCAD-i variandi osas saate ise hakkama. Loodan, et siin esitatud materjal leiab oma „kliente”.

Aitäh tähelepanu eest!

Allikas: habr.com