Пры распрацоўцы плагінаў для САПР прыкладанняў ( гэта 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++) і знаходзім там запіс аб нашым пакеце. Выглядае яна зараз так:
<PackageReference Include="ModPlus.Revit.API.2015">
<Version>1.0.0</Version>
</PackageReference>Дадаем яму ўласцівасць runtime. Атрымаецца вось так:
<PackageReference Include="ModPlus.Revit.API.2015">
<Version>1.0.0</Version>
<ExcludeAssets>runtime</ExcludeAssets>
</PackageReference>Зараз пры пабудове праекту файлы з пакета не будуць капіявацца ў выходную тэчку.
Ідзем далей - адразу ўявім, што наша плягін будзе выкарыстоўваць нешта з 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", "Hello Revit 2015");
#elif R2016
TaskDialog.Show("ModPlus", "Hello Revit 2016");
#elif R2017
TaskDialog.Show("ModPlus", "Hello Revit 2017");
#elif R2018
TaskDialog.Show("ModPlus", "Hello Revit 2018");
#elif R2019
TaskDialog.Show("ModPlus", "Hello Revit 2019");
#elif R2020
TaskDialog.Show("ModPlus", "Hello Revit 2020");
#endif
return Result.Succeeded;
}
}
}Я адразу ўлічыў усе версіі Revit вышэй за 2015 версіі (якія былі на момант напісання артыкула) і адразу ўлічыў наяўнасць сімвалаў умоўнай кампіляцыі, якія ў мяне ствараюцца па аднолькавым шаблоне.
Пераходзім да галоўнай разыначкі. Ствараем новы праект у нашым рашэнні, толькі ўжо для версіі плагіна пад Revit 2016. Паўтараем усе апісаныя вышэй дзеянні, адпаведна, замяняючы лік 2015 на лік 2016. Але файл Class1.cs з новага праекту выдаляем.
Файл з патрэбным кодам - Class1.cs - У нас ужо ёсць і нам трэба проста ўставіць на яго спасылку ў новым праекце. Ёсць два шляхі ўстаўкі спасылак:
- Доўгі – ціснем на праекце правай кнопкай мышкі, выбіраемы пункт «Дадаць»->«Існуючы элемент», у якое адкрылася акне знаходзім патрэбны файл і замест варыянту «Дадаць» выбіраемы варыянт «Дадаць як сувязь»
- кароткі – прамы ў аглядальніку рашэнняў выбіраемы патрэбны файл (ці нават файлы. А можна нават цэлыя тэчкі) і перацягваем у новы праект з заціснутай клавішай Alt. Пры перацягванні вы ўбачыце, што пры націску клавішы Alt курсор на мышцы будзе мяняцца з плюсіка на стрэлачку.
UPD: Я крыху ўнёс смуты ў гэтым параграфе - каб пераносіць некалькі файлаў варта заціскаць Shift + Alt!
Пасля правядзення працэдуры ў нас з'явіцца ў другім праекце файл Class1.cs з адпаведным абразком (сіняя стрэлачка):
Пры рэдагаванні кода ў акне рэдактара вы таксама можаце выбіраць у кантэксце якога праекта адлюстроўваць код, што дазволіць вам бачыць рэдагаваць код пры розных сімвалах умоўнай кампіляцыі:
Па гэтай схеме ствараем усе астатнія праекты (2017-2020). Лайфхак - калі перацягваць файлы ў аглядальніку рашэнняў не з базавага праекта, а з праекта, дзе яны ўжо ўстаўленыя як сувязь, то можна не заціскаць клавішу Alt!
Апісаны варыянт суцэль добры да моманту дадання новай версіі плагіна або да моманту дадання ў праект новых файлаў – усё гэта становіцца вельмі моташным. А нядаўна я раптам раптоўна ўсвядоміў як усё гэта разруліць адным праектам і мы пераходзім да другога спосабу.
Магія канфігурацый
Дачытаўшы сюды, вы можаце ўсклікнуць «А нафіг ты апісваў першы спосаб, калі артыкул адразу пра другі?!». А апісаў я ўсё, каб было ясней для чаго нам патрэбны сімвалы ўмоўнай кампіляцыі і ў якіх месцах у нас адрозніваюцца праекты. І зараз нам становіцца ясней, якія менавіта адрозненні праектаў нам трэба рэалізаваць, пакінуўшы ўсяго адзін праект.
І каб усё было больш відавочным, мы не будзем ствараць новага праекту, а занясем змены ў наш бягучы праект, створаны першым спосабам.
Такім чынам, у першую чаргу выдаляем з рашэння ўсе праекты, акрамя асноўнага (які змяшчае непасрэдна файлы). Г.зн. праекты для версій 2016-2020. Адкрываем тэчку з рашэннем і выдаляем тамака тэчкі гэтых праектаў.
У нас у рашэнні застаўся адзін праект - MySuperPluginForRevit_2015. Адкрываем яго ўласцівасці і:
- На ўкладцы «Дадатак» з імя зборкі выдаляем суфікс _2015 (далей стане зразумела навошта)
- На ўкладцы «зборка» выдаляем сімвал умоўнай кампіляцыі R2015 з адпаведнага поля
Нататка: у апошняй версіі Visual Studio маецца глюк – знакі ўмоўнай кампіляцыі не выводзяцца ў акне ўласцівасцяў праекту, хоць яны маюцца. Калі ў вас гэты глюк назіраецца, то вам трэба выдаляць іх уручную з файла .csproj. Аднак, нам усё роўна працаваць у ім, так што чытэльны далей.
Пераназываем праект у акне аглядальніка рашэнняў, выдаліўшы суфікс _2015 і затым выдаляем праект з рашэння. Гэта трэба для падтрымання парадку і пачуццяў перфекцыяністаў! Адкрываем тэчку нашага рашэння, пераназываем тамака такім жа чынам тэчку праекта і загружаем праект зваротна ў рашэнне.
Адкрываем дыспетчар канфігурацый. Нам канфігурацыя Адпусціце у прынцыпе не патрэбна будзе, таму выдаляем яе. Ствараем новыя канфігурацыі з ужо звыклымі нам імёнамі R2015, R2016, ..., R2020. Звярніце ўвагу, што не трэба капіраваць параметры з іншых канфігурацый і не трэба ствараць канфігурацыі праекта:
Ідзем у тэчку з праектам і адчыняны файл з пашырэннем .csproj у зручным вам рэдактары. Дарэчы, яго можна адкрыць і ў Visual Studio - трэба выгрузіць праект і затым у кантэкстным меню будзе патрэбны пункт:
Рэдагаваць у Visual Studio нават пераважней, бо рэдактар і выраўноўвае і падказвае.
У файле мы ўбачым элементы - у самым версе ідзе агульны, а следам ідуць з умовамі. Гэтыя элементы задаюць уласцівасці праекту пры яго зборцы. Першы элемент, які без умоў, задае агульныя ўласцівасці, а элементы з умовамі, адпаведна, мяняюць некаторыя ўласцівасці ў залежнасці ад канфігурацый.
Пераходзім у агульны (першы) элемент 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-пакетамі). Калі паглядзець далей, мы ўбачым, што якія падключаюцца бібліятэкі задаюцца элементах . Але вось няўдача - гэты элемент няслушна апрацоўвае ўмовы, як элемент PropertyGroup. Магчыма гэта нават глюк Visual Studio, але калі задаць некалькі элементаў ItemGroup з умовамі канфігурацый, а ўсярэдзіне ўставіць розныя спасылкі на NuGet-пакеты, то пры змене канфігурацыі да праекту падлучаюцца ўсе паказаныя пакеты.
На дапамогу нам прыходзіць элемент , які працуе па звыклай нам логіцы калі-то-інакш.
Выкарыстоўваючы элемент Выбіраць, задаём розныя NuGet-пакеты для розных канфігурацый:
Усе змесціва csproj
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="15.0" ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
<ProjectGuid>{5AD738D6-4122-4E76-B865-BE7CE0F6B3EB}</ProjectGuid>
<OutputType>Library</OutputType>
<AppDesignerFolder>Properties</AppDesignerFolder>
<RootNamespace>MySuperPluginForRevit</RootNamespace>
<AssemblyName>MySuperPluginForRevit</AssemblyName>
<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
<FileAlignment>512</FileAlignment>
<Deterministic>true</Deterministic>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
<Optimize>false</Optimize>
<OutputPath>binDebug</OutputPath>
<DefineConstants>DEBUG;R2015</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'R2015|AnyCPU' ">
<OutputPath>binR2015</OutputPath>
<DefineConstants>TRACE;R2015</DefineConstants>
<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
<AssemblyName>$(AssemblyName)_2015</AssemblyName>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'R2016|AnyCPU' ">
<OutputPath>binR2016</OutputPath>
<DefineConstants>TRACE;R2016</DefineConstants>
<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
<AssemblyName>$(AssemblyName)_2016</AssemblyName>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'R2017|AnyCPU' ">
<OutputPath>binR2017</OutputPath>
<DefineConstants>TRACE;R2017</DefineConstants>
<TargetFrameworkVersion>v4.5.2</TargetFrameworkVersion>
<AssemblyName>$(AssemblyName)_2017</AssemblyName>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'R2018|AnyCPU' ">
<OutputPath>binR2018</OutputPath>
<DefineConstants>TRACE;R2018</DefineConstants>
<TargetFrameworkVersion>v4.5.2</TargetFrameworkVersion>
<AssemblyName>$(AssemblyName)_2018</AssemblyName>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'R2019|AnyCPU' ">
<OutputPath>binR2019</OutputPath>
<DefineConstants>TRACE;R2019</DefineConstants>
<TargetFrameworkVersion>v4.7</TargetFrameworkVersion>
<AssemblyName>$(AssemblyName)_2019</AssemblyName>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'R2020|AnyCPU' ">
<OutputPath>binR2020</OutputPath>
<DefineConstants>TRACE;R2020</DefineConstants>
<TargetFrameworkVersion>v4.7</TargetFrameworkVersion>
<AssemblyName>$(AssemblyName)_2020</AssemblyName>
</PropertyGroup>
<ItemGroup>
<Reference Include="System" />
<Reference Include="System.Core" />
<Reference Include="System.Xml.Linq" />
<Reference Include="System.Data.DataSetExtensions" />
<Reference Include="Microsoft.CSharp" />
<Reference Include="System.Data" />
<Reference Include="System.Net.Http" />
<Reference Include="System.Xml" />
</ItemGroup>
<ItemGroup>
<Compile Include="Class1.cs" />
<Compile Include="PropertiesAssemblyInfo.cs" />
</ItemGroup>
<Choose>
<When Condition=" '$(Configuration)'=='R2015' ">
<ItemGroup>
<PackageReference Include="ModPlus.Revit.API.2015">
<Version>1.0.0</Version>
<ExcludeAssets>runtime</ExcludeAssets>
</PackageReference>
</ItemGroup>
</When>
<When Condition=" '$(Configuration)'=='R2016' ">
<ItemGroup>
<PackageReference Include="ModPlus.Revit.API.2016">
<Version>1.0.0</Version>
<ExcludeAssets>runtime</ExcludeAssets>
</PackageReference>
</ItemGroup>
</When>
<When Condition=" '$(Configuration)'=='R2017' ">
<ItemGroup>
<PackageReference Include="ModPlus.Revit.API.2017">
<Version>1.0.0</Version>
<ExcludeAssets>runtime</ExcludeAssets>
</PackageReference>
</ItemGroup>
</When>
<When Condition=" '$(Configuration)'=='R2018' ">
<ItemGroup>
<PackageReference Include="ModPlus.Revit.API.2018">
<Version>1.0.0</Version>
<ExcludeAssets>runtime</ExcludeAssets>
</PackageReference>
</ItemGroup>
</When>
<When Condition=" '$(Configuration)'=='R2019' ">
<ItemGroup>
<PackageReference Include="ModPlus.Revit.API.2019">
<Version>1.0.0</Version>
<ExcludeAssets>runtime</ExcludeAssets>
</PackageReference>
</ItemGroup>
</When>
<When Condition=" '$(Configuration)'=='R2020' or '$(Configuration)'=='Debug'">
<ItemGroup>
<PackageReference Include="ModPlus.Revit.API.2020">
<Version>1.0.0</Version>
<ExcludeAssets>runtime</ExcludeAssets>
</PackageReference>
</ItemGroup>
</When>
</Choose>
<Import Project="$(MSBuildToolsPath)Microsoft.CSharp.targets" />
</Project>Звярніце ўвагу, што ў адной з умоў я паказаў дзве канфігурацыі праз АБО (Or). Такім чынам будзе падлучацца патрэбны пакет пры канфігурацыі. Адладжваць.
І вось у нас амаль усё ідэальна. Загружаем зваротна праект, уключаем патрэбную нам канфігурацыю, выкліканы ў кантэкстным меню рашэння (не праекту) пункт «Аднавіць усе пакеты NuGet»і бачым як у нас мяняюцца пакеты.
І вось на гэтым этапе я прыйшоў у тупік - каб сабраць адразу ўсе канфігурацыі мы маглі б скарыстацца пакетнай зборкай (меню «зборка»->«Пакетная зборка»), але пры пераключэнні канфігурацый не адбываецца аўтаматычнага аднаўлення пакетаў. І пры зборцы праекту таксама не адбываецца, хоць, па ідэі, павінна. Рашэння гэтай праблемы стандартнымі сродкамі я так і не знайшоў. І хутчэй за ўсё гэта таксама баг Visual Studio.
Таму для пакетнай зборкі вырашана было выкарыстоўваць адмысловую сістэму аўтаматызаванай зборкі. . Насамрэч я гэтага не хацеў, бо лічу гэта залішнім у рамках распрацоўкі плагінаў, але на дадзены момант іншага рашэння я не бачу. А на пытанне "Чаму менавіта Nuke?" адказ просты - выкарыстоўваем на працы.
Такім чынам, пераходзім у тэчку нашага рашэння (не праекту), заціскаем клавішу Зрух і клікаем правай кнопкай мышкі па пустым месцы ў тэчцы - у кантэкстным меню выбіраем пункт «Адкрыць акно PowerShell тут.
Калі ў вас не ўсталяваны ядзерную зброю, то спачатку пішыце каманду
dotnet tool install Nuke.GlobalTool –globalЦяпер пішыце каманду ядзерную зброю і вам будзе прапанавана наладзіць ядзерную зброю для бягучага праекта. Не ведаю як гэта правільней напісаць на рускай мове - на англійскай будзе напісана Could not find .nuke file. Як ты хацеў пабудаваць? [y/n]
Націскаем клавішу Y і далей будуць непасрэдныя пункты наладкі. Нам патрэбен самы просты варыянт з выкарыстаннем MSBuild, таму адказваем як на скрыншоце:
Пяройдзем у Visual Studio, якая нам прапануе перазагрузіць рашэнне, бо ў яго дададзены новы праект. Перазагружаем рашэнне і бачым, што ў нас з'явіўся праект будаваць у якім нас цікавіць толькі адзін файл – 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<Build>(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<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"));
}
});
}Вяртаемся ў акно PowerShell і зноў пішам каманду ядзерную зброю (можна пісаць каманду ядзерную зброю з указаннем патрэбнага Мэта. Але ў нас адзін Мэта, які запускаецца па змаўчанні). Пасля націску клавішы Enter мы адчуем сябе сапраўднымі хакерамі, бо як у кіно будзе адбывацца аўтаматычная зборка нашага праекту пад розныя канфігурацыі.
Дарэчы, можна выкарыстоўваць PowerShell прамы з Visual Studio.Выгляд»->«Іншыя вокны»->«Кансоль дыспетчара пакетаў»), але там усё будзе чорна-белым, што не вельмі зручна.
На гэтым мой артыкул скончаны. Упэўнены, што з варыянтам для AutoCAD вы зможаце разабрацца самі. Спадзяюся, што выкладзены тут матэрыял знойдзе сваіх "кліентаў".
Дзякуй за ўвагу!
Крыніца: habr.com