Amikor bővítményeket fejlesztünk CAD alkalmazásokhoz ( ezek az AutoCAD, a Revit és a Renga) idővel egy probléma jelenik meg - a programok új verziói jelennek meg, API-módosításaik és a bővítmények új verzióira van szükség.
Ha csak egy beépülő modulja van, vagy még mindig autodidakta kezdő ebben a kérdésben, egyszerűen készíthet másolatot a projektről, módosíthatja benne a szükséges helyeket, és összeállíthatja a bővítmény új verzióját. Ennek megfelelően a kódex későbbi módosításai a munkaerőköltségek többszörös növekedését vonják maguk után.
Amint tapasztalatot és tudást szerez, számos módot talál majd ennek a folyamatnak a automatizálására. Bejártam ezt az utat, és el akarom mondani, mire jutottam, és mennyire kényelmes.
Először is nézzünk meg egy olyan módszert, amely kézenfekvő, és amelyet már régóta alkalmazok.
Projektfájlok hivatkozásai
És hogy minden egyszerű, vizuális és érthető legyen, mindent leírok a bővítményfejlesztés absztrakt példájával.
Nyissuk meg a Visual Studio-t (nekem a Community 2019-es verziója van. És igen - oroszul), és hozzunk létre egy új megoldást. Hívjuk fel MySuperPluginForRevit
Elkészítjük a Revit bővítményt a 2015-2020-as verziókhoz. Ezért hozzunk létre egy új projektet a megoldásban (Net Framework Class Library), és hívjuk meg MySuperPluginForRevit_2015
Hivatkozásokat kell hozzáadnunk a Revit API-hoz. Természetesen hozzáadhatunk hivatkozásokat a helyi fájlokhoz (az összes szükséges SDK-t vagy a Revit összes verzióját telepítenünk kell), de azonnal követjük a helyes utat, és csatlakoztatjuk a NuGet csomagot. Elég sok csomagot találsz, de én a sajátomat fogom használni.
A csomag csatlakoztatása után kattintson jobb gombbal a tételre "referenciák"és válassza ki az elemet"A packages.config áthelyezése a PackageReference fájlba...»
Ha ezen a ponton hirtelen pánikba kezd, mert a csomag tulajdonságai ablakban nem lesz fontos elem "Másolás helyben", amit mindenképpen be kell állítanunk az értékre hamis, akkor ne essen pánikba - menjen a projektet tartalmazó mappába, nyissa meg a .csproj kiterjesztésű fájlt egy Önnek megfelelő szerkesztőben (én Notepad++-t használok), és ott keressen egy bejegyzést a csomagunkról. Most így néz ki:
<PackageReference Include="ModPlus.Revit.API.2015">
<Version>1.0.0</Version>
</PackageReference>Adjon hozzá egy tulajdonságot futásidő. Így fog kiderülni:
<PackageReference Include="ModPlus.Revit.API.2015">
<Version>1.0.0</Version>
<ExcludeAssets>runtime</ExcludeAssets>
</PackageReference>Most, amikor egy projektet épít, a csomagból származó fájlok nem kerülnek a kimeneti mappába.
Menjünk tovább – azonnal képzeljük el, hogy a bővítményünk valamit a Revit API-ból fog használni, ami az idők során megváltozott az új verziók megjelenésekor. Nos, vagy egyszerűen módosítanunk kell valamit a kódban attól függően, hogy a Revit melyik verziójához készítjük a bővítményt. A kódbeli különbségek feloldásához feltételes fordítási szimbólumokat használunk. Nyissa meg a projekt tulajdonságait, lépjen a „ fülregyülekezés"és a mezőn"Feltételes összeállítási jelölés"írjunk R2015.
Ne feledje, hogy a szimbólumot mind a Debug, mind a Release konfigurációkhoz hozzá kell adni.
Nos, amíg a tulajdonságok ablakban vagyunk, azonnal a „ lapra lépünkApp"és a mezőn"Alapértelmezett névtér» távolítsa el az utótagot _2015így a névterünk univerzális és független az összeállítás nevétől:
Esetemben a végtermékben az összes verzió beépülő modulja egy mappába kerül, így az összeállítási neveim az űrlap utótagjával maradnak _20хх. De az utótagot is eltávolíthatja az összeállítás nevéből, ha a fájlok feltételezhetően különböző mappákban találhatók.
Menjünk a fájl kódjához Class1.cs és szimuláljon ott valamilyen kódot, figyelembe véve a Revit különböző verzióit:
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;
}
}
}Azonnal figyelembe vettem a Revit 2015-ös verzió feletti összes verzióját (amelyek a cikk írásakor elérhetők voltak), és azonnal figyelembe vettem a feltételes fordítási szimbólumok jelenlétét, amelyek ugyanazzal a sablonnal jönnek létre.
Térjünk át a fő kiemelésre. Megoldásunkban új projektet hozunk létre, csak a Revit 2016 bővítmény verziójához. Megismételjük a fent leírt lépéseket, és a 2015-ös számot 2016-ra cseréljük. Class1.cs törölje az új projektből.
Fájl a szükséges kóddal - Class1.cs – már megvan, és csak egy linket kell beillesztenünk egy új projektbe. A hivatkozások beszúrásának két módja van:
- Hosszú – kattintson a jobb gombbal a projektre, és válassza a „Add»->«Meglévő elem", a megnyíló ablakban keresse meg a kívánt fájlt, és az "opció helyett"Add"válasszon opciót"Hozzáadás kapcsolatként»
- rövid – közvetlenül a megoldásböngészőben válassza ki a kívánt fájlt (vagy akár fájlokat, vagy akár teljes mappákat), és húzza át egy új projektbe, miközben lenyomva tartja az Alt billentyűt. A húzás során látni fogja, hogy az Alt billentyű megnyomásakor az egérkurzor pluszjelről nyílra változik.
UPS: Kis zavart okoztam ebben a bekezdésben – több fájl átviteléhez tartsa lenyomva Shift + Alt!
Az eljárás elvégzése után a második projektben lesz egy fájlunk Class1.cs a megfelelő ikonnal (kék nyíl):
A szerkesztő ablakban történő kód szerkesztése során azt is kiválaszthatja, hogy melyik projektkörnyezetben jelenítse meg a kódot, ami lehetővé teszi, hogy a szerkesztett kódot különböző feltételes fordítási szimbólumok alatt lássa:
Az összes többi projektet (2017-2020) ezzel a sémával hozzuk létre. Life hack - ha nem az alapprojektből húzza át a fájlokat a Solution Explorerben, hanem abból a projektből, ahol már hivatkozásként be vannak szúrva, akkor nem kell lenyomva tartania az Alt billentyűt!
A leírt lehetőség egészen jó a bővítmény új verziójának hozzáadásának pillanatáig vagy addig, amíg új fájlokat nem adunk a projekthez - mindez nagyon unalmassá válik. Nemrég pedig hirtelen rájöttem, hogyan lehet mindent megoldani egy projekttel, és áttérünk a második módszerre
A konfigurációk varázsa
Ha befejezte az olvasást, felkiálthat: "Miért írtad le az első módszert, ha a cikk rögtön a másodikról szól?!" És leírtam mindent, hogy érthetőbb legyen, miért van szükségünk feltételes összeállítási szimbólumokra, és milyen helyeken térnek el a projektjeink. És most világossá válik számunkra, hogy pontosan milyen projektek közötti különbségeket kell megvalósítanunk, így csak egy projekt marad.
És hogy minden nyilvánvalóbb legyen, nem új projektet hozunk létre, hanem az első módon létrehozott jelenlegi projektünket módosítjuk.
Tehát mindenekelőtt az összes projektet eltávolítjuk a megoldásból, kivéve a fő projektet (amely közvetlenül tartalmazza a fájlokat). Azok. projektek a 2016-2020-as verziókhoz. Nyissa meg a megoldást tartalmazó mappát, és törölje ott ezen projektek mappáit.
Egyetlen projektünk maradt a döntésünk előtt - MySuperPluginForRevit_2015. Nyissa meg a tulajdonságait, és:
- A laponApp" távolítsa el az utótagot az összeállítás nevéből _2015 (később kiderül, miért)
- A lapongyülekezés» távolítsa el a feltételes fordítási szimbólumot R2015 a megfelelő mezőből
Megjegyzés: a Visual Studio legújabb verziójában hiba van – a feltételes fordítási szimbólumok nem jelennek meg a projekt tulajdonságai ablakban, bár rendelkezésre állnak. Ha ezt a hibát tapasztalja, manuálisan kell eltávolítania őket a .csproj fájlból. Azonban még dolgoznunk kell benne, úgyhogy olvass tovább.
Nevezze át a projektet a Solution Explorer ablakban az utótag eltávolításával _2015 majd távolítsa el a projektet a megoldásból. Ez szükséges a rend és a perfekcionisták érzéseinek fenntartásához! Megnyitjuk megoldásunk mappáját, ott ugyanígy átnevezzük a projekt mappát és visszatöltjük a projektet a megoldásba.
Nyissa meg a konfigurációkezelőt. Amerikai konfiguráció Engedje elvileg nem lesz rá szükség, ezért töröljük. Új konfigurációkat hozunk létre a számunkra már ismert nevekkel R2015, R2016, ..., R2020. Vegye figyelembe, hogy nem kell más konfigurációkból átmásolnia a beállításokat, és nem kell projektkonfigurációkat létrehoznia:
Lépjen a projektet tartalmazó mappába, és nyissa meg a .csproj kiterjesztésű fájlt egy Önnek megfelelő szerkesztőben. Egyébként a Visual Studio-ban is megnyithatja - ki kell töltenie a projektet, és a kívánt elem megjelenik a helyi menüben:
A Visual Studioban való szerkesztés még előnyösebb, mivel a szerkesztő egyszerre igazítja és kéri.
A fájlban látni fogjuk az elemeket – a legtetején az általános, aztán jönnek a feltételek. Ezek az elemek határozzák meg a projekt tulajdonságait a felépítéskor. Az első elem, amely feltétel nélküli, általános tulajdonságokat állít be, a feltételekkel rendelkező elemek pedig ennek megfelelően bizonyos tulajdonságokat változtatnak a konfigurációktól függően.
Lépjen a közös (első) elemre PropertyGroup és nézd meg az ingatlant AssemblyName – ez az összeállítás neve, és utótag nélkül kellene _2015. Ha van utótag, akkor távolítsa el.
Feltételes elem keresése
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">Nincs rá szükségünk – töröljük.
Elem állapottal
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">szükség lesz a kódfejlesztés és hibakeresés szakaszában való munkához. Tulajdonságait igényeinek megfelelően módosíthatja – különböző kimeneti utakat állíthat be, módosíthatja a feltételes fordítási szimbólumokat stb.
Most hozzunk létre új elemeket PropertyGroup konfigurációink számára. Ezekben az elemekben mindössze négy tulajdonságot kell beállítanunk:
- Kimeneti út - kimeneti mappa. Beállítottam az alapértelmezett értéket binR20xx
- DefineConstants – feltételes összeállítási szimbólumok. Az értéket meg kell adni TRACE;R20хх
- TargetFrameworkVersion – platform verzió. A Revit API különböző verzióihoz különböző platformokat kell megadni.
- AssemblyName – összeállítás neve (azaz fájlnév). Leírhatod az összeállítás pontos nevét, de a sokoldalúság kedvéért javaslom az érték írását $(AssemblyName)_20хх. Ehhez korábban eltávolítottuk az utótagot az összeállítás nevéből
Mindezen elemek legfontosabb jellemzője, hogy egyszerűen átmásolhatók más projektekbe anélkül, hogy megváltoztatnák őket. Később a cikkben csatolom a .csproj fájl teljes tartalmát.
Oké, kitaláltuk a projekt tulajdonságait – ez nem nehéz. De mi a teendő a beépülő könyvtárakkal (NuGet csomagokkal). Ha tovább nézzük, látni fogjuk, hogy a benne foglalt könyvtárak az elemekben vannak megadva . De balszerencse - ez az elem elemként helytelenül dolgozza fel a feltételeket PropertyGroup. Talán ez még a Visual Studio hibája is, de ha több elemet ad meg ItemGroup konfigurációs feltételekkel, és illesszen be különböző hivatkozásokat a NuGet-csomagokra, majd amikor módosítja a konfigurációt, az összes megadott csomag kapcsolódik a projekthez.
Az elem a segítségünkre van , ami a megszokott logikánk szerint működik ha-akkor-más.
Elem használata A pop-art design, négy időzóna kijelzése egyszerre és méretének arányai azok az érvek, amelyek a NeXtime Time Zones-t kiváló választássá teszik. Válassza a, különböző NuGet-csomagokat állítunk be a különböző konfigurációkhoz:
Minden tartalom 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>Kérjük, vegye figyelembe, hogy az egyik feltételben két konfigurációt adtam meg keresztül VAGY. Így a konfiguráció során a szükséges csomag csatlakozik Debug.
És itt szinte minden tökéletes. Visszatöltjük a projektet, engedélyezzük a szükséges konfigurációt, meghívjuk a „” elemet a megoldás helyi menüjében (nem a projekt)Állítsa vissza az összes NuGet-csomagot"és látjuk, hogyan változnak a csomagjaink.
És ebben a szakaszban zsákutcába jutottam - hogy az összes konfigurációt egyszerre gyűjtsük össze, használhatjuk a kötegelt összeállítást (menü "gyülekezés»->«Batch build"), de konfigurációváltáskor a csomagok nem állnak vissza automatikusan. És a projekt összeállításakor ez szintén nem történik meg, bár elméletileg ennek kellene lennie. Nem találtam megoldást erre a problémára szabványos eszközökkel. És valószínűleg ez is a Visual Studio hibája.
Ezért a kötegelt összeszereléshez speciális automatizált összeszerelési rendszer alkalmazása mellett döntöttek . Valójában nem ezt akartam, mert szerintem túlzás a bővítményfejlesztés szempontjából, de jelenleg nem látok más megoldást. És arra a kérdésre, hogy „Miért a Nuke?” A válasz egyszerű – a munkahelyünkön használjuk.
Tehát menjen a megoldásunk mappájába (ne a projekthez), tartsa lenyomva a gombot műszak és jobb gombbal kattintson a mappában egy üres helyre - a helyi menüben válassza ki a „Nyissa meg a PowerShell ablakot itt".
Ha nincs telepítve nuke, majd először írja ki a parancsot
dotnet tool install Nuke.GlobalTool –globalMost írja be a parancsot nuke és a rendszer felkéri a konfigurálásra nuke az aktuális projekthez. Nem tudom, hogyan írjam le helyesebben oroszul - angolul ez lesz írva. Nem található a .nuke fájl. Építést szeretne beállítani? [i/n]
Nyomja meg az Y billentyűt, és ott lesznek a közvetlen beállítások. A legegyszerűbb lehetőségre van szükségünk MSBuild, tehát a képernyőképen látható módon válaszolunk:
Lépjünk a Visual Studio-ra, amely felszólít a megoldás újratöltésére, mivel egy új projekt került hozzá. Újratöltjük a megoldást, és látjuk, hogy van egy projektünk épít amelyben csak egy fájl érdekel minket - Build.cs
Nyissa meg ezt a fájlt, és írjon egy szkriptet a projekt felépítéséhez az összes konfigurációhoz. Nos, vagy használja az én szkriptemet, amelyet igényei szerint szerkeszthet:
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"));
}
});
}Visszatérünk a PowerShell ablakhoz, és újra írjuk a parancsot nuke (írhatod a parancsot nuke a szükséges feltüntetésével cél. De nekünk van egy cél, amely alapértelmezés szerint fut). Az Enter billentyű lenyomása után igazi hackernek fogjuk érezni magunkat, ugyanis, mint egy filmben, a projektünk automatikusan összeáll különböző konfigurációkra.
A PowerShell egyébként közvetlenül a Visual Studióból is használható (menüKilátás»->«Más ablakok»->«Csomagkezelő konzol"), de minden fekete-fehér lesz, ami nem túl kényelmes.
Ezzel zárom cikkemet. Biztos vagyok benne, hogy maga is kitalálja az AutoCAD opciót. Remélem, hogy az itt bemutatott anyag megtalálja „megrendelőit”.
Спасибо за внимание!
Forrás: will.com