Dum disvolvado de kromaĵoj por CAD-aplikoj ( ĉi tiuj estas AutoCAD, Revit kaj Renga) kun la tempo, unu problemo aperas - novaj versioj de programoj estas publikigitaj, iliaj API-ŝanĝoj kaj novaj versioj de kromaĵoj devas esti faritaj.
Kiam vi havas nur unu kromaĵon aŭ vi ankoraŭ estas memlernita komencanto en ĉi tiu afero, vi povas simple fari kopion de la projekto, ŝanĝi la necesajn lokojn en ĝi kaj kunmeti novan version de la kromaĵo. Sekve, postaj ŝanĝoj al la kodo kunportos multoblan pliigon de laborkostoj.
Dum vi akiras sperton kaj scion, vi trovos plurajn manierojn aŭtomatigi ĉi tiun procezon. Mi marŝis ĉi tiun vojon kaj mi volas diri al vi, kion mi finis kaj kiom oportuna ĝi estas.
Unue, ni rigardu metodon, kiu estas evidenta kaj kiun mi delonge uzas.
Ligiloj al projektdosieroj
Kaj por fari ĉion simpla, vida kaj komprenebla, mi priskribos ĉion uzante abstraktan ekzemplon de kromprogramo.
Ni malfermu Visual Studio (mi havas la version Komunumo 2019. Kaj jes - en la rusa) kaj kreu novan solvon. Ni voku lin MySuperPluginForRevit
Ni faros kromprogramon por Revit por versioj 2015-2020. Tial ni kreu novan projekton en la solvo (Net Framework Class Library) kaj nomu ĝin MySuperPluginForRevit_2015
Ni devas aldoni ligilojn al la Revit API. Kompreneble, ni povas aldoni ligilojn al lokaj dosieroj (ni devos instali ĉiujn necesajn SDK-ojn aŭ ĉiujn versiojn de Revit), sed ni tuj sekvos la ĝustan vojon kaj konektos la pakaĵon NuGet. Vi povas trovi sufiĉe multajn pakaĵojn, sed mi uzos la miajn.
Post konekti la pakaĵon, dekstre alklaku la eron "referencoj" kaj elektu la eron "Movu packages.config al PackageReference...»
Se subite ĉe ĉi tiu punkto vi ekpanikos, ĉar en la pakaĵa propra fenestro estos neniu grava ero "Kopiu loke", kiun ni certe devas agordi al la valoro falsa, tiam ne paniku - iru al la dosierujo kun la projekto, malfermu la dosieron kun la etendo .csproj en redaktilo konvena por vi (mi uzas Notepad++) kaj trovu tie enskribon pri nia pako. Ŝi nun aspektas jene:
<PackageReference Include="ModPlus.Revit.API.2015">
<Version>1.0.0</Version>
</PackageReference>Aldonu posedaĵon al ĝi rultempo. Ĝi rezultos tiel:
<PackageReference Include="ModPlus.Revit.API.2015">
<Version>1.0.0</Version>
<ExcludeAssets>runtime</ExcludeAssets>
</PackageReference>Nun, dum konstruado de projekto, dosieroj de la pakaĵo ne estos kopiitaj al la eliga dosierujo.
Ni iru plu - ni tuj imagu, ke nia kromaĵo uzos ion el la Revit API, kiu ŝanĝiĝis laŭlonge de la tempo kiam novaj versioj estis publikigitaj. Nu, aŭ ni nur bezonas ŝanĝi ion en la kodo depende de la versio de Revit por kiu ni faras la kromprogramon. Por solvi tiajn diferencojn en kodo, ni uzos kondiĉajn kompilsimbolojn. Malfermu la projektojn, iru al la langeto "Asembleo"kaj sur la kampo"Kondiĉa kompilnotacio"ni skribu R2015.
Notu, ke la simbolo devas esti aldonita por kaj la Sencimiga kaj Liberiga agordoj.
Nu, dum ni estas en la fenestro de proprietoj, ni tuj iras al la langeto "Apliko"kaj sur la kampo"Defaŭlta nomspaco» forigi la sufikson _2015tiel ke nia nomspaco estas universala kaj sendependa de la kunignomo:
En mia kazo, en la fina produkto, kromprogramoj de ĉiuj versioj estas metitaj en unu dosierujon, do miaj kunignomoj restas kun la sufikso de la formo _20хх. Sed vi ankaŭ povas forigi la sufikson de la asemblea nomo se la dosieroj supozeble troviĝas en malsamaj dosierujoj.
Ni iru al la dosierkodo Class1.cs kaj simulu iun kodon tie, konsiderante malsamajn versiojn 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", "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;
}
}
}Mi tuj enkalkulis ĉiujn versiojn de Revit super la versio 2015 (kiuj estis disponeblaj en la momento de la skribado) kaj tuj enkalkulis la ĉeeston de kondiĉaj kompilsimboloj, kiuj estas kreitaj per la sama ŝablono.
Ni transiru al la ĉefa elstaraĵo. Ni kreas novan projekton en nia solvo, nur por la versio de la kromaĵo por Revit 2016. Ni ripetas ĉiujn paŝojn priskribitajn supre respektive, anstataŭigante la numeron 2015 per la numero 2016. Sed la dosiero Class1.cs forigu de la nova projekto.
Dosiero kun la bezonata kodo - Class1.cs – ni jam havas ĝin kaj ni nur bezonas enmeti ligilon al ĝi en nova projekto. Estas du manieroj enigi ligilojn:
- Longa - dekstre alklaku la projekton kaj elektu "Aldoni»->«Ekzistanta elemento", en la fenestro kiu malfermiĝas, trovu la bezonatan dosieron kaj anstataŭ la opcion "Aldoni" elektu la opcion "Aldonu kiel konekton»
- Mallonga – rekte en la esploristo de solvoj, elektu la deziratan dosieron (aŭ eĉ dosierojn, aŭ eĉ tutajn dosierujojn) kaj trenu ĝin en novan projekton tenante la Alt-klavon. Dum vi trenas, vi vidos, ke kiam vi premas la Altklavon, la muskursoro ŝanĝiĝos de plus-signo al sago.
UPS: Mi faris iom da konfuzo en ĉi tiu alineo - por translokigi plurajn dosierojn vi devus teni premita Maj + Alt!
Post plenumi la proceduron, ni havos dosieron en la dua projekto Class1.cs kun la responda piktogramo (blua sago):
Dum redaktado de kodo en la redaktora fenestro, vi ankaŭ povas elekti en kiu projekta kunteksto montri la kodon, kio permesos al vi vidi la kodon redaktata sub malsamaj kondiĉaj kompilsimboloj:
Ni kreas ĉiujn aliajn projektojn (2017-2020) uzante ĉi tiun skemon. Viva hako - se vi trenas dosierojn en la Solvo-Esplorilo ne de la baza projekto, sed de la projekto, kie ili jam estas enmetitaj kiel ligilo, tiam vi ne devas teni la Alt-klavon!
La priskribita opcio estas sufiĉe bona ĝis la momento de aldoni novan version de la kromaĵo aŭ ĝis la momento de aldoni novajn dosierojn al la projekto - ĉio ĉi fariĝas tre teda. Kaj lastatempe mi subite subite komprenis kiel ordigi ĉion per unu projekto kaj ni iras al la dua metodo.
La magio de agordoj
Fininte legi ĉi tie, vi povas ekkrii: "Kial vi priskribis la unuan metodon, se la artikolo tuj temas pri la dua?!" Kaj mi priskribis ĉion por klarigi kial ni bezonas kondiĉajn kompilsimbolojn kaj en kiuj lokoj niaj projektoj diferencas. Kaj nun fariĝas pli klare al ni precize kiajn diferencojn en projektoj ni devas efektivigi, lasante nur unu projekton.
Kaj por fari ĉion pli evidenta, ni ne kreos novan projekton, sed faros ŝanĝojn al nia nuna projekto kreita laŭ la unua maniero.
Do, unue, ni forigas ĉiujn projektojn el la solvo krom la ĉefa (enhavanta la dosierojn rekte). Tiuj. projektoj por versioj 2016-2020. Malfermu la dosierujon kun la solvo kaj forigu la dosierujojn de ĉi tiuj projektoj tie.
Al ni restas unu projekto en nia decido - MySuperPluginForRevit_2015. Malfermu ĝiajn ecojn kaj:
- Sur la langeto "Apliko"forigu la sufikson de la kunignomo _2015 (klariĝos kial poste)
- Sur la langeto "Asembleo» forigi la kondiĉan kompilsimbolon R2015 de la responda kampo
Noto: la plej nova versio de Visual Studio havas cimon - kondiĉaj kompilsimboloj ne estas montrataj en la fenestro de la projekto, kvankam ili estas disponeblaj. Se vi spertas ĉi tiun problemon, tiam vi devas forigi ilin permane el la .csproj dosiero. Tamen ni ankoraŭ devas labori en ĝi, do legu plu.
Alinomi la projekton en la fenestro de Solvo-Esplorilo per forigo de la sufikso _2015 kaj poste forigu la projekton el la solvo. Ĉi tio estas necesa por konservi ordon kaj sentojn de perfektistoj! Ni malfermas la dosierujon de nia solvo, renomas la projektan dosierujon tie same kaj ŝargas la projekton reen en la solvon.
Malfermu la agordan administranton. usona agordo ĵeto principe, ĝi ne estos bezonata, do ni forigas ĝin. Ni kreas novajn agordojn kun nomoj jam konataj al ni R2015, R2016,..., R2020. Notu, ke vi ne bezonas kopii agordojn de aliaj agordoj kaj vi ne bezonas krei projektajn agordojn:
Iru al la dosierujo kun la projekto kaj malfermu la dosieron kun la etendo .csproj en redaktilo konvena por vi. Cetere, vi ankaŭ povas malfermi ĝin en Visual Studio - vi devas malŝarĝi la projekton kaj tiam la dezirata elemento estos en la kunteksta menuo:
Redakti en Visual Studio estas eĉ preferinda, ĉar la redaktilo kaj vicigas kaj instigas.
En la dosiero ni vidos la elementojn – supre estas la ĝenerala, kaj poste venas la kondiĉoj. Ĉi tiuj elementoj starigas la ecojn de la projekto kiam ĝi estas konstruita. La unua elemento, kiu estas sen kondiĉoj, starigas ĝeneralajn ecojn, kaj elementoj kun kondiĉoj, sekve, ŝanĝas iujn ecojn depende de la agordoj.
Iru al la komuna (unua) elemento PropertyGroup kaj rigardu la posedaĵon AssemblyName – jen la nomo de la asembleo kaj ni havu ĝin sen sufikso _2015. Se estas sufikso, tiam forigu ĝin.
Trovi elementon kun kondiĉo
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">Ni ne bezonas ĝin - ni forigas ĝin.
Elemento kun kondiĉo
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">estos bezonata por labori en la stadio de koda evoluo kaj sencimigado. Vi povas ŝanĝi ĝiajn ecojn laŭ viaj bezonoj - agordi malsamajn eligvojojn, ŝanĝi kondiĉajn kompilsimbolojn ktp.
Nun ni kreu novajn elementojn PropertyGroup por niaj agordoj. En ĉi tiuj elementoj ni nur bezonas agordi kvar ecojn:
- Eligo Vojo - eligo dosierujo. Mi starigis la defaŭltan valoron binR20xx
- Difini Konstantojn – kondiĉaj kompilsimboloj. La valoro estu specifita TRACE;R20хх
- TargetFrameworkVersion - platforma versio. Malsamaj versioj de la Revit API postulas malsamajn platformojn esti specifitaj.
- AssemblyName – asembleonomo (t.e. dosiernomo). Vi povas skribi la ĝustan nomon de la aro, sed por ĉiuflankeco mi rekomendas skribi la valoron $(AssemblyName)_20хх. Por fari tion, ni antaŭe forigis la sufikson de la kunignomo
La plej grava trajto de ĉiuj ĉi tiuj elementoj estas, ke ili simple povas esti kopiitaj en aliajn projektojn sen ŝanĝi ilin entute. Poste en la artikolo mi aldonos la tutan enhavon de la dosiero .csproj.
Bone, ni eltrovis la trajtojn de la projekto - ĝi ne estas malfacila. Sed kion fari kun aldonaĵaj bibliotekoj (NuGet-pakaĵoj). Se ni rigardas plu, ni vidos, ke la inkluzivitaj bibliotekoj estas specifitaj en la elementoj . Sed malbonŝanco - ĉi tiu elemento malĝuste prilaboras la kondiĉojn kiel elementon PropertyGroup. Eble ĉi tio estas eĉ malfunkcio de Visual Studio, sed se vi specifas plurajn elementojn ItemGroup kun agordaj kondiĉoj, kaj enmetu malsamajn ligilojn al NuGet-pakaĵoj interne, tiam kiam vi ŝanĝas la agordon, ĉiuj specifitaj pakaĵoj estas konektitaj al la projekto.
La elemento venas al nia helpo , kiu funkcias laŭ nia kutima logiko se-tiam-alie.
Uzanta elementon elektu, ni starigas malsamajn NuGet-pakaĵojn por malsamaj agordoj:
Ĉiuj enhavoj 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>Bonvolu noti, ke en unu el la kondiĉoj mi specifis du agordojn per AŬ. Tiel la bezonata pako estos konektita dum agordo Depuŝo.
Kaj ĉi tie ni havas preskaŭ ĉion perfektan. Ni ŝarĝas la projekton reen, ebligas la agordon, kiun ni bezonas, nomas la eron " en la kunteksta menuo de la solvo (ne la projekto)Restarigu ĉiujn NuGet-pakaĵojn"kaj ni vidas kiel niaj pakaĵoj ŝanĝiĝas.
Kaj en ĉi tiu etapo mi venis al sakstrato - por kolekti ĉiujn agordojn samtempe, ni povus uzi batan asembleon (menuo "Asembleo»->«Bata konstruo"), sed dum ŝanĝado de agordoj, pakaĵoj ne estas aŭtomate restarigitaj. Kaj kiam oni muntas la projekton, ĉi tio ankaŭ ne okazas, kvankam, en teorio, ĝi devus. Mi ne trovis solvon al ĉi tiu problemo per normaj rimedoj. Kaj plej verŝajne ĉi tio ankaŭ estas cimo de Visual Studio.
Tial, por bata muntado, estis decidite uzi specialan aŭtomatigitan asembleon . Mi fakte ne volis ĉi tion ĉar mi pensas, ke ĝi estas troa rilate al disvolvado de kromprogramoj, sed nuntempe mi ne vidas alian solvon. Kaj al la demando "Kial Nuke?" La respondo estas simpla - ni uzas ĝin ĉe la laboro.
Do, iru al la dosierujo de nia solvo (ne la projekto), tenu la klavon Shift kaj dekstre alklaku malplenan spacon en la dosierujo - en la kunteksta menuo elektu la eron "Malfermu PowerShell-fenestron ĉi tie".
Se vi ne havas ĝin instalita nuke, tiam unue skribu la komandon
dotnet tool install Nuke.GlobalTool –globalNun skribu la komandon nuke kaj oni petos vin agordi nuke por la nuna projekto. Mi ne scias kiel skribi ĉi tion pli ĝuste en la rusa - en la angla ĝi estos skribita Could not find .nuke file. Ĉu vi volas agordi konstruaĵon? [j/n]
Premu la Y-klavon kaj tiam estos rektaj agordaj eroj. Ni bezonas la plej simplan eblon uzante MSBuild, do ni respondas kiel en la ekrankopio:
Ni iru al Visual Studio, kiu instigos nin reŝargi la solvon, ĉar nova projekto estis aldonita al ĝi. Ni reŝargas la solvon kaj vidas, ke ni havas projekton konstruu pri kiu ni interesiĝas nur pri unu dosiero - Build.cs
Malfermu ĉi tiun dosieron kaj skribu skripton por konstrui la projekton por ĉiuj agordoj. Nu, aŭ uzu mian skripton, kiun vi povas redakti laŭ viaj bezonoj:
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"));
}
});
}Ni revenas al la fenestro de PowerShell kaj skribas la komandon denove nuke (vi povas skribi la komandon nuke indikante la postulatan Cel. Sed ni havas unu Cel, kiu funkcias defaŭlte). Post premado de la Enter-klavo, ni sentos nin kiel veraj hackers, ĉar, kiel en filmo, nia projekto estos aŭtomate kunmetita por malsamaj agordoj.
Cetere, vi povas uzi PowerShell rekte de Visual Studio (menuo "vido»->«Aliaj fenestroj»->«Paka Administra Konzolo"), sed ĉio estos en nigra kaj blanka, kio ne estas tre oportuna.
Ĉi tio finas mian artikolon. Mi certas, ke vi mem povas eltrovi la opcion por AutoCAD. Mi esperas, ke la ĉi tie prezentita materialo trovos siajn "klientojn".
Спасибо за внимание!
fonto: www.habr.com