Når du utvikler plugins for CAD-applikasjoner ( disse er AutoCAD, Revit og Renga) over tid, ett problem dukker opp - nye versjoner av programmer er utgitt, API-endringer og nye versjoner av plugins må lages.
Når du bare har ett plugin eller du fortsatt er en selvlært nybegynner i denne saken, kan du ganske enkelt lage en kopi av prosjektet, endre de nødvendige stedene i det og sette sammen en ny versjon av plugin. Følgelig vil påfølgende endringer i koden innebære en multippel økning i arbeidskostnadene.
Etter hvert som du får erfaring og kunnskap, vil du finne flere måter å automatisere denne prosessen på. Jeg gikk denne stien og jeg vil fortelle deg hva jeg endte opp med og hvor praktisk det er.
La oss først se på en metode som er åpenbar og som jeg har brukt lenge.
Lenker til prosjektfiler
Og for å gjøre alt enkelt, visuelt og forståelig, vil jeg beskrive alt ved å bruke et abstrakt eksempel på plugin-utvikling.
La oss åpne Visual Studio (jeg har Community 2019-versjonen. Og ja - på russisk) og lage en ny løsning. La oss ringe ham MySuperPluginForRevit
Vi skal lage en plugin for Revit for versjoner 2015-2020. La oss derfor lage et nytt prosjekt i løsningen (Net Framework Class Library) og kalle det MySuperPluginForRevit_2015
Vi må legge til lenker til Revit API. Selvfølgelig kan vi legge til lenker til lokale filer (vi må installere alle nødvendige SDK-er eller alle versjoner av Revit), men vi vil umiddelbart følge den riktige veien og koble til NuGet-pakken. Du finner ganske mange pakker, men jeg skal bruke min egen.
Etter å ha koblet til pakken, høyreklikk på elementet "referanser" og velg elementet "Flytt packages.config til PackageReference...»
Hvis du plutselig på dette tidspunktet begynner å få panikk, fordi det ikke vil være noe viktig element i vinduet for pakkeegenskaper "Kopier lokalt", som vi definitivt må sette til verdien falsk, så ikke få panikk - gå til mappen med prosjektet, åpne filen med .csproj-utvidelsen i en editor som er praktisk for deg (jeg bruker Notepad++) og finn en oppføring om pakken vår der. Hun ser slik ut nå:
<PackageReference Include="ModPlus.Revit.API.2015">
<Version>1.0.0</Version>
</PackageReference>Legg til en egenskap til den kjøretid. Det vil bli slik:
<PackageReference Include="ModPlus.Revit.API.2015">
<Version>1.0.0</Version>
<ExcludeAssets>runtime</ExcludeAssets>
</PackageReference>Nå, når du bygger et prosjekt, vil ikke filer fra pakken bli kopiert til utdatamappen.
La oss gå videre – la oss umiddelbart forestille oss at vår plugin vil bruke noe fra Revit API, som har endret seg over tid når nye versjoner har blitt sluppet. Vel, eller så trenger vi bare å endre noe i koden avhengig av hvilken versjon av Revit vi lager plugin for. For å løse slike forskjeller i kode, vil vi bruke betingede kompileringssymboler. Åpne prosjektegenskapene, gå til fanen "sammenstilling"og i feltet"Betinget kompileringsnotasjon"la oss skrive R2015.
Merk at symbolet må legges til både for feilsøkings- og utgivelseskonfigurasjonene.
Vel, mens vi er i egenskapsvinduet, går vi umiddelbart til fanen "App"og i feltet"Standard navneområde» fjern suffikset _2015slik at navneområdet vårt er universelt og uavhengig av samlingsnavnet:
I mitt tilfelle, i sluttproduktet, legges plugins av alle versjoner i én mappe, så samlingsnavnene mine forblir med suffikset til skjemaet _20хх. Men du kan også fjerne suffikset fra samlingsnavnet hvis filene skal være plassert i forskjellige mapper.
La oss gå til filkoden Klasse1.cs og simuler litt kode der, tar hensyn til forskjellige versjoner av 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;
}
}
}Jeg tok umiddelbart hensyn til alle versjoner av Revit over versjon 2015 (som var tilgjengelige i skrivende stund) og tok umiddelbart hensyn til tilstedeværelsen av betingede kompileringssymboler, som er opprettet ved hjelp av samme mal.
La oss gå videre til hovedhøydepunktet. Vi oppretter et nytt prosjekt i vår løsning, kun for versjonen av plugin for Revit 2016. Vi gjentar alle trinnene beskrevet ovenfor, henholdsvis erstatter nummeret 2015 med nummeret 2016. Men filen Klasse1.cs slette fra det nye prosjektet.
Fil med den nødvendige koden - Klasse1.cs – vi har det allerede, og vi trenger bare å sette inn en lenke til det i et nytt prosjekt. Det er to måter å sette inn lenker på:
- Lang – høyreklikk på prosjektet og velg “Legg»->«Eksisterende element", i vinduet som åpnes, finn den nødvendige filen og i stedet for alternativet "Legg"velg alternativet"Legg til som tilkobling»
- kort – direkte i løsningsutforskeren, velg ønsket fil (eller til og med filer, eller til og med hele mapper) og dra den inn i et nytt prosjekt mens du holder nede Alt-tasten. Mens du drar, vil du se at når du trykker på Alt-tasten, vil musepekeren endres fra et plusstegn til en pil.
OPP: Jeg gjorde litt forvirring i dette avsnittet - for å overføre flere filer bør du holde nede Skift + Alt!
Etter å ha utført prosedyren vil vi ha en fil i det andre prosjektet Klasse1.cs med det tilsvarende ikonet (blå pil):
Når du redigerer kode i redigeringsvinduet, kan du også velge hvilken prosjektkontekst du vil vise koden i, noe som lar deg se koden redigeres under forskjellige betingede kompileringssymboler:
Vi oppretter alle andre prosjekter (2017-2020) ved hjelp av denne ordningen. Life hack - hvis du drar filer i Solution Explorer ikke fra basisprosjektet, men fra prosjektet der de allerede er satt inn som en lenke, trenger du ikke holde nede Alt-tasten!
Det beskrevne alternativet er ganske bra til øyeblikket du legger til en ny versjon av plugin-en eller til øyeblikket du legger til nye filer til prosjektet - alt dette blir veldig kjedelig. Og nylig skjønte jeg plutselig hvordan jeg skulle ordne alt med ett prosjekt, og vi går videre til den andre metoden
Magien med konfigurasjoner
Etter å ha lest ferdig her, kan du utbryte: "Hvorfor beskrev du den første metoden, hvis artikkelen umiddelbart handler om den andre?!" Og jeg beskrev alt for å gjøre det tydeligere hvorfor vi trenger betingede kompileringssymboler og på hvilke steder prosjektene våre er forskjellige. Og nå blir det tydeligere for oss nøyaktig hvilke forskjeller i prosjekter vi trenger å gjennomføre, og det er bare ett prosjekt igjen.
Og for å gjøre alt mer åpenbart, vil vi ikke opprette et nytt prosjekt, men vil gjøre endringer i vårt nåværende prosjekt opprettet på den første måten.
Så først og fremst fjerner vi alle prosjekter fra løsningen bortsett fra det viktigste (som inneholder filene direkte). De. prosjekter for versjoner 2016-2020. Åpne mappen med løsningen og slett mappene til disse prosjektene der.
Vi har ett prosjekt igjen i vår beslutning - MySuperPluginForRevit_2015. Åpne egenskapene og:
- På fanen "App"fjern suffikset fra sammenstillingsnavnet _2015 (det vil bli klart hvorfor senere)
- På fanen "sammenstilling» fjern det betingede kompileringssymbolet R2015 fra det tilsvarende feltet
Merk: den nyeste versjonen av Visual Studio har en feil - betingede kompileringssymboler vises ikke i vinduet med prosjektegenskaper, selv om de er tilgjengelige. Hvis du opplever denne feilen, må du fjerne dem manuelt fra .csproj-filen. Men vi må fortsatt jobbe med det, så les videre.
Gi prosjektet nytt navn i Solution Explorer-vinduet ved å fjerne suffikset _2015 og fjern deretter prosjektet fra løsningen. Dette er nødvendig for å opprettholde orden og følelsene til perfeksjonister! Vi åpner mappen til løsningen vår, gir nytt navn til prosjektmappen der på samme måte og laster prosjektet tilbake i løsningen.
Åpne konfigurasjonsbehandlingen. amerikansk konfigurasjon Slipp i prinsippet vil det ikke være nødvendig, så vi sletter det. Vi lager nye konfigurasjoner med navn som allerede er kjent for oss R2015, R2016, ..., R2020. Merk at du ikke trenger å kopiere innstillinger fra andre konfigurasjoner, og du trenger ikke opprette prosjektkonfigurasjoner:
Gå til mappen med prosjektet og åpne filen med filtypen .csproj i en editor som passer deg. Forresten, du kan også åpne det i Visual Studio - du må laste ut prosjektet og deretter vil ønsket element være i kontekstmenyen:
Redigering i Visual Studio er til og med å foretrekke, siden editoren både justerer og ber om.
I filen vil vi se elementene – Helt på toppen er den generelle, og så kommer forholdene. Disse elementene setter egenskapene til prosjektet når det bygges. Det første elementet, som er uten betingelser, setter generelle egenskaper, og elementer med betingelser endrer følgelig noen egenskaper avhengig av konfigurasjonene.
Gå til det vanlige (første) elementet Eiendomsgruppe og se på eiendommen Forsamlingsnavn – dette er navnet på forsamlingen og vi skal ha den uten suffiks _2015. Hvis det er et suffiks, fjern det.
Finne et element med en betingelse
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">Vi trenger det ikke – vi sletter det.
Element med tilstand
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">vil være nødvendig for å fungere på stadiet av kodeutvikling og feilsøking. Du kan endre egenskapene for å passe dine behov - angi forskjellige utgangsbaner, endre betingede kompileringssymboler, etc.
La oss nå lage nye elementer Eiendomsgruppe for våre konfigurasjoner. I disse elementene trenger vi bare å angi fire egenskaper:
- OutputPath – utgangsmappe. Jeg angir standardverdien binR20xx
- Definer konstanter – betingede samlingssymboler. Verdien bør spesifiseres TRACE;R20хх
- TargetFrameworkVersion – plattformversjon. Ulike versjoner av Revit API krever at forskjellige plattformer spesifiseres.
- Forsamlingsnavn – samlingsnavn (dvs. filnavn). Du kan skrive det nøyaktige navnet på sammenstillingen, men for allsidighet anbefaler jeg å skrive verdien $(AssemblyName)_20хх. For å gjøre dette fjernet vi tidligere suffikset fra samlingsnavnet
Den viktigste egenskapen til alle disse elementene er at de ganske enkelt kan kopieres inn i andre prosjekter uten å endre dem i det hele tatt. Senere i artikkelen vil jeg legge ved alt innholdet i .csproj-filen.
Ok, vi har funnet ut egenskapene til prosjektet - det er ikke vanskelig. Men hva skal man gjøre med plugin-biblioteker (NuGet-pakker). Ser vi videre vil vi se at de inkluderte bibliotekene er spesifisert i elementene . Men uflaks - dette elementet behandler forholdene feil som et element Eiendomsgruppe. Kanskje dette til og med er en Visual Studio-feil, men hvis du spesifiserer flere elementer Varegruppe med konfigurasjonsbetingelser, og sett inn forskjellige lenker til NuGet-pakker inne, så når du endrer konfigurasjonen, kobles alle spesifiserte pakker til prosjektet.
Elementet kommer oss til hjelp , som fungerer i henhold til vår vanlige logikk hvis-da-annet.
Bruker element Velg, setter vi forskjellige NuGet-pakker for forskjellige konfigurasjoner:
Alt innhold 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>Vær oppmerksom på at i en av betingelsene spesifiserte jeg to konfigurasjoner via ELLER. På denne måten vil den nødvendige pakken kobles til under konfigurasjonen Debug.
Og her har vi nesten alt perfekt. Vi laster prosjektet tilbake, aktiverer konfigurasjonen vi trenger, kaller elementet " i kontekstmenyen til løsningen (ikke prosjektet)Gjenopprett alle NuGet-pakker"og vi ser hvordan pakkene våre endrer seg.
Og på dette stadiet kom jeg til en blindvei - for å samle alle konfigurasjonene på en gang, kunne vi bruke batchmontering (meny "sammenstilling»->«Batchbygg"), men når du bytter konfigurasjoner, blir ikke pakker automatisk gjenopprettet. Og når du setter sammen prosjektet, skjer dette heller ikke, selv om det i teorien burde. Jeg har ikke funnet en løsning på dette problemet ved bruk av standard midler. Og mest sannsynlig er dette også en Visual Studio-feil.
Derfor, for batchmontering, ble det besluttet å bruke et spesielt automatisert monteringssystem . Jeg ønsket faktisk ikke dette fordi jeg synes det er overkill når det gjelder utvikling av plugin, men for øyeblikket ser jeg ingen annen løsning. Og til spørsmålet "Hvorfor Nuke?" Svaret er enkelt – vi bruker det på jobb.
Så gå til mappen for løsningen vår (ikke prosjektet), hold nede tasten Skift og høyreklikk på en tom plass i mappen - i kontekstmenyen velg elementet "Åpne PowerShell-vinduet her'.
Hvis du ikke har den installert nuke, så skriv først kommandoen
dotnet tool install Nuke.GlobalTool –globalSkriv nå kommandoen nuke og du vil bli bedt om å konfigurere nuke for det aktuelle prosjektet. Jeg vet ikke hvordan jeg skal skrive dette mer korrekt på russisk - på engelsk vil det bli skrevet Kunne ikke finne .nuke-filen. Ønsker du å sette opp en build? [y/n]
Trykk på Y-tasten og så vil det være direkte innstillinger. Vi trenger det enkleste alternativet ved å bruke MSBuild, så vi svarer som på skjermbildet:
La oss gå til Visual Studio, som vil be oss om å laste inn løsningen på nytt, siden et nytt prosjekt er lagt til den. Vi laster inn løsningen på nytt og ser at vi har et prosjekt bygge der vi bare er interessert i én fil - Build.cs
Åpne denne filen og skriv et skript for å bygge prosjektet for alle konfigurasjoner. Vel, eller bruk skriptet mitt, som du kan redigere for å passe dine behov:
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"));
}
});
}Vi går tilbake til PowerShell-vinduet og skriver kommandoen på nytt nuke (du kan skrive kommandoen nuke som indikerer det nødvendige Target. Men vi har en Target, som kjører som standard). Etter å ha trykket på Enter-tasten, vil vi føle oss som ekte hackere, fordi, som i en film, vil prosjektet vårt automatisk settes sammen for forskjellige konfigurasjoner.
Du kan forresten bruke PowerShell direkte fra Visual Studio (meny "Vis»->«Andre vinduer»->«Pakkebehandlingskonsoll"), men alt vil være i svart-hvitt, noe som ikke er veldig praktisk.
Dette avslutter artikkelen min. Jeg er sikker på at du kan finne ut alternativet for AutoCAD selv. Jeg håper at materialet som presenteres her vil finne sine "klienter".
Takk for din oppmerksomhet!
Kilde: www.habr.com