Podczas opracowywania wtyczek do aplikacji CAD ( są to AutoCAD, Revit i Renga) z biegiem czasu pojawia się jeden problem - wydawane są nowe wersje programów, konieczne są zmiany w ich API i nowe wersje wtyczek.
Jeśli posiadasz tylko jedną wtyczkę lub jesteś jeszcze początkującym samoukiem w tej kwestii, możesz po prostu wykonać kopię projektu, zmienić w nim niezbędne miejsca i zmontować nową wersję wtyczki. W związku z tym kolejne zmiany w kodeksie będą wiązać się z wielokrotnym wzrostem kosztów pracy.
W miarę zdobywania doświadczenia i wiedzy znajdziesz kilka sposobów na automatyzację tego procesu. Szedłem tą ścieżką i chcę ci powiedzieć, co skończyłem i jakie to wygodne.
Najpierw spójrzmy na metodę, która jest oczywista i którą stosuję od dłuższego czasu.
Linki do plików projektu
A żeby wszystko było proste, wizualne i zrozumiałe, opiszę wszystko na abstrakcyjnym przykładzie rozwoju wtyczki.
Otwórzmy Visual Studio (mam wersję Community 2019. I tak - po rosyjsku) i stwórzmy nowe rozwiązanie. Zadzwońmy do niego MySuperPluginForRevit
Będziemy tworzyć wtyczkę do programu Revit dla wersji 2015-2020. Stwórzmy zatem w rozwiązaniu nowy projekt (Biblioteka klas Net Framework) i wywołajmy go MojaSuperPluginForRevit_2015
Musimy dodać łącza do Revit API. Możemy oczywiście dodać linki do plików lokalnych (będziemy musieli zainstalować wszystkie niezbędne SDK lub wszystkie wersje Revitu), ale od razu pójdziemy właściwą ścieżką i podłączymy pakiet NuGet. Możesz znaleźć sporo pakietów, ale ja użyję własnego.
Po podłączeniu pakietu kliknij prawym przyciskiem myszy element „referencje" i wybierz element "Przenieś pakiety.config do PackageReference...»
Jeśli nagle w tym momencie zaczniesz panikować, ponieważ w oknie właściwości pakietu nie będzie ważnej pozycji „Skopiuj lokalnie", który zdecydowanie musimy ustawić na wartość fałszywy, to nie panikuj - przejdź do folderu z projektem, otwórz plik z rozszerzeniem .csproj w wygodnym dla Ciebie edytorze (ja używam Notepad++) i znajdź tam wpis dotyczący naszej paczki. Wygląda teraz tak:
<PackageReference Include="ModPlus.Revit.API.2015">
<Version>1.0.0</Version>
</PackageReference>Dodaj do niego właściwość czas wykonania. To się okaże tak:
<PackageReference Include="ModPlus.Revit.API.2015">
<Version>1.0.0</Version>
<ExcludeAssets>runtime</ExcludeAssets>
</PackageReference>Teraz podczas budowania projektu pliki z pakietu nie będą kopiowane do folderu wyjściowego.
Pójdźmy dalej – wyobraźmy sobie od razu, że nasza wtyczka będzie korzystała z czegoś z Revit API, które z biegiem czasu ulegało zmianom wraz z wydawaniem nowych wersji. No cóż, albo po prostu musimy zmienić coś w kodzie w zależności od wersji Revita, dla której tworzymy wtyczkę. Aby rozwiązać takie różnice w kodzie, użyjemy symboli kompilacji warunkowej. Otwórz właściwości projektu, przejdź do zakładki „montaż" i w terenie "Notacja kompilacji warunkowej"napiszmy R2015.
Należy pamiętać, że symbol należy dodać zarówno dla konfiguracji debugowania, jak i wydania.
Cóż, będąc w oknie właściwości, od razu przechodzimy do zakładki „Aplikacja" i w terenie "Domyślna przestrzeń nazw» usuń przyrostek _2015aby nasza przestrzeń nazw była uniwersalna i niezależna od nazwy zestawu:
W moim przypadku w produkcie końcowym wtyczki wszystkich wersji są umieszczone w jednym folderze, więc nazwy moich zestawów pozostają z przyrostkiem formularza _20хх. Ale możesz także usunąć przyrostek z nazwy zestawu, jeśli pliki mają znajdować się w różnych folderach.
Przejdźmy do kodu pliku Klasa 1.cs i zasymuluj tam jakiś kod, biorąc pod uwagę różne wersje Revita:
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;
}
}
}Od razu wziąłem pod uwagę wszystkie wersje Revita powyżej wersji 2015 (które były dostępne w momencie pisania tego tekstu) i od razu wziąłem pod uwagę obecność symboli kompilacji warunkowej, które są tworzone przy użyciu tego samego szablonu.
Przejdźmy do najważniejszego wydarzenia. W naszym rozwiązaniu tworzymy nowy projekt, tylko dla wersji wtyczki do programu Revit 2016. Wszystkie opisane powyżej kroki powtarzamy odpowiednio, zastępując liczbę 2015 liczbą 2016. Jednak plik Klasa 1.cs usuń z nowego projektu.
Plik z wymaganym kodem - Klasa 1.cs – już go mamy i pozostaje nam tylko wstawić link do niego w nowym projekcie. Linki można wstawiać na dwa sposoby:
- Długi – kliknij projekt prawym przyciskiem myszy i wybierz „dodaj„->”Istniejący element„, w oknie, które zostanie otwarte, znajdź wymagany plik i zamiast opcji „dodaj"wybierz opcję"Dodaj jako połączenie»
- Krótki – bezpośrednio w eksploratorze rozwiązań wybierz żądany plik (lub nawet pliki, a nawet całe foldery) i przeciągnij go do nowego projektu, przytrzymując klawisz Alt. Podczas przeciągania zobaczysz, że po naciśnięciu klawisza Alt kursor myszy zmieni się ze znaku plus na strzałkę.
UPD: Zrobiłem w tym akapicie małe zamieszanie - aby przenieść kilka plików należy przytrzymać Shift + Alt!
Po przeprowadzeniu procedury będziemy mieli plik w drugim projekcie Klasa 1.cs z odpowiednią ikoną (niebieska strzałka):
Edytując kod w oknie edytora, możesz także wybrać kontekst projektu, w którym chcesz wyświetlić kod, co pozwoli Ci zobaczyć edytowany kod pod różnymi symbolami kompilacji warunkowej:
Wszystkie pozostałe projekty (2017-2020) tworzymy według tego schematu. Life hack - jeśli przeciągniesz pliki w Eksploratorze rozwiązań nie z projektu bazowego, ale z projektu, w którym są już wstawione jako link, to nie musisz przytrzymywać klawisza Alt!
Opisana opcja jest całkiem dobra do momentu dodania nowej wersji wtyczki lub do momentu dodania nowych plików do projektu - wszystko to staje się bardzo uciążliwe. A ostatnio nagle nagle zdałem sobie sprawę, jak to wszystko załatwić jednym projektem i przechodzimy do drugiej metody
Magia konfiguracji
Po zakończeniu czytania możesz zawołać: „Dlaczego opisałeś pierwszą metodę, skoro artykuł od razu dotyczy drugiej?!”. A opisałem wszystko, żeby było jaśniejsze po co nam symbole kompilacji warunkowej i w jakich miejscach nasze projekty się różnią. A teraz staje się dla nas jaśniejsze, jakie dokładnie różnice w projektach musimy wdrożyć, pozostawiając tylko jeden projekt.
I żeby wszystko było bardziej oczywiste, nie będziemy tworzyć nowego projektu, ale dokonamy zmian w naszym obecnym projekcie, utworzonym w pierwszy sposób.
Zatem w pierwszej kolejności usuwamy z rozwiązania wszystkie projekty oprócz głównego (zawierającego bezpośrednio pliki). Te. projekty dla wersji 2016-2020. Otwórz folder z rozwiązaniem i usuń tam foldery tych projektów.
Pozostał nam jeden projekt do podjęcia decyzji - MojaSuperPluginForRevit_2015. Otwórz jego właściwości i:
- Na karcie „Aplikacja„usuń przyrostek z nazwy zestawu _2015 (później stanie się jasne dlaczego)
- Na karcie „montaż» usuń symbol kompilacji warunkowej R2015 z odpowiedniego pola
Uwaga: najnowsza wersja Visual Studio ma błąd - symbole kompilacji warunkowej nie są wyświetlane w oknie właściwości projektu, mimo że są dostępne. Jeśli doświadczysz tego błędu, musisz usunąć je ręcznie z pliku .csproj. Musimy jednak jeszcze nad tym popracować, więc czytajcie dalej.
Zmień nazwę projektu w oknie Eksplorator rozwiązań, usuwając przyrostek _2015 a następnie usuń projekt z rozwiązania. Jest to konieczne, aby zachować porządek i poczucie perfekcjonizmu! Otwieramy folder naszego rozwiązania, w ten sam sposób zmieniamy nazwę folderu projektu i wczytujemy projekt z powrotem do rozwiązania.
Otwórz menedżera konfiguracji. Konfiguracja amerykańska Wydanie w zasadzie nie będzie potrzebny, więc go usuwamy. Tworzymy nowe konfiguracje o znanych nam już nazwach R2015, R2016, ..., R2020. Pamiętaj, że nie musisz kopiować ustawień z innych konfiguracji i nie musisz tworzyć konfiguracji projektu:
Przejdź do folderu z projektem i otwórz plik z rozszerzeniem .csproj w wygodnym dla Ciebie edytorze. Nawiasem mówiąc, możesz go również otworzyć w Visual Studio - musisz wyładować projekt, a wtedy żądana pozycja pojawi się w menu kontekstowym:
Edycja w programie Visual Studio jest nawet lepsza, ponieważ edytor zarówno wyrównuje, jak i wyświetla monity.
W pliku zobaczymy elementy – na samej górze jest ogólne, a potem pojawiają się warunki. Elementy te ustawiają właściwości projektu po jego zbudowaniu. Pierwszy element, który nie ma warunków, ustawia ogólne właściwości, a elementy z warunkami odpowiednio zmieniają niektóre właściwości w zależności od konfiguracji.
Przejdź do wspólnego (pierwszego) elementu Grupa właściwości i obejrzyj nieruchomość Nazwa zespołu – to nazwa zgromadzenia i powinniśmy ją mieć bez przyrostka _2015. Jeśli istnieje przyrostek, usuń go.
Znajdowanie elementu z warunkiem
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">Nie potrzebujemy tego - usuwamy to.
Element z warunkiem
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">będzie potrzebny do pracy na etapie tworzenia kodu i debugowania. Możesz zmieniać jego właściwości według własnych potrzeb - ustawiać różne ścieżki wyjściowe, zmieniać symbole kompilacji warunkowej itp.
Teraz utwórzmy nowe elementy Grupa właściwości dla naszych konfiguracji. W tych elementach wystarczy ustawić cztery właściwości:
- Ścieżka wyjściowa - folder wyjściowy. Ustawiłem wartość domyślną binR20xx
- Zdefiniuj stałe – symbole kompilacji warunkowej. Należy określić wartość Ślad;R20хх
- Wersja TargetFramework – wersja platformowa. Różne wersje interfejsu Revit API wymagają określenia różnych platform.
- Nazwa zespołu – nazwa zestawu (czyli nazwa pliku). Możesz wpisać dokładną nazwę zestawu, ale dla wszechstronności zalecam zapisanie wartości $(Nazwa Zespołu)_20хх. Aby to zrobić, wcześniej usunęliśmy przyrostek z nazwy zestawu
Najważniejszą cechą wszystkich tych elementów jest to, że można je po prostu skopiować do innych projektów, nie zmieniając ich wcale. W dalszej części artykułu załączę całą zawartość pliku .csproj.
OK, ustaliliśmy właściwości projektu - to nie jest trudne. Ale co zrobić z bibliotekami wtyczek (pakiety NuGet). Jeśli spojrzymy dalej, zobaczymy, że dołączone biblioteki są określone w elementach . Ale pech - ten element błędnie przetwarza warunki jako element Grupa właściwości. Być może jest to nawet usterka programu Visual Studio, ale jeśli określisz kilka elementów Grupa przedmiotów z warunkami konfiguracji i wstaw w środku różne linki do pakietów NuGet, a następnie po zmianie konfiguracji wszystkie określone pakiety zostaną połączone z projektem.
Z pomocą przychodzi nam żywioł , co działa zgodnie z naszą zwykłą logiką jeśli-to-jeszcze.
Korzystanie z elementu Dodaj, ustawiamy różne pakiety NuGet dla różnych konfiguracji:
Cała zawartość 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>Proszę zwrócić uwagę, że w jednym z warunków określiłem dwie konfiguracje via LUB. W ten sposób wymagany pakiet zostanie podłączony podczas konfiguracji Debug.
A tutaj mamy prawie wszystko idealne. Ładujemy projekt z powrotem, włączamy potrzebną konfigurację, wywołujemy pozycję „w menu kontekstowym rozwiązania (nie projektu)Przywróć wszystkie pakiety NuGet„i widzimy, jak zmieniają się nasze pakiety.
I na tym etapie doszedłem do ślepego zaułka – aby zebrać wszystkie konfiguracje na raz, moglibyśmy zastosować montaż wsadowy (menu „montaż„->”Kompilacja wsadowa"), ale przy zmianie konfiguracji pakiety nie są automatycznie przywracane. A podczas montażu projektu tak się również nie dzieje, choć teoretycznie powinno. Nie znalazłem rozwiązania tego problemu za pomocą standardowych środków. Najprawdopodobniej jest to również błąd programu Visual Studio.
Dlatego też do montażu wsadowego zdecydowano się zastosować specjalny zautomatyzowany system montażu . Właściwie tego nie chciałem, ponieważ uważam, że to przesada z punktu widzenia rozwoju wtyczek, ale w tej chwili nie widzę innego rozwiązania. A na pytanie „Dlaczego Nuke?” Odpowiedź jest prosta – używamy go w pracy.
Przejdźmy więc do folderu naszego rozwiązania (nie projektu), przytrzymaj klawisz Shift i kliknij prawym przyciskiem myszy puste miejsce w folderze - w menu kontekstowym wybierz element „Otwórz tutaj okno PowerShell".
Jeśli nie masz go zainstalowanego nuke, a następnie najpierw napisz polecenie
dotnet tool install Nuke.GlobalTool –globalTeraz napisz polecenie nuke i zostaniesz poproszony o konfigurację nuke dla bieżącego projektu. Nie wiem, jak napisać to poprawniej po rosyjsku - po angielsku zostanie napisane Nie można znaleźć pliku .nuke. Czy chcesz skonfigurować kompilację? [t/n]
Naciśnij klawisz Y, a następnie pojawią się elementy ustawień bezpośrednich. Potrzebujemy najprostszej opcji za pomocą MSBuild, więc odpowiadamy jak na zrzucie ekranu:
Przejdźmy do Visual Studio, które poprosi nas o przeładowanie rozwiązania, gdyż został do niego dodany nowy projekt. Wczytujemy rozwiązanie ponownie i widzimy, że mamy projekt budować w którym interesuje nas tylko jeden plik - Kompiluj.cs
Otwórz ten plik i napisz skrypt, aby zbudować projekt dla wszystkich konfiguracji. Cóż, albo skorzystaj z mojego skryptu, który możesz edytować według swoich potrzeb:
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"));
}
});
}Wracamy do okna PowerShell i ponownie wpisujemy polecenie nuke (możesz napisać polecenie nuke wskazując wymagane cel. Ale mamy jednego cel, który działa domyślnie). Po naciśnięciu klawisza Enter poczujemy się jak prawdziwi hakerzy, ponieważ niczym w filmie nasz projekt zostanie automatycznie zmontowany do różnych konfiguracji.
Nawiasem mówiąc, możesz używać PowerShell bezpośrednio z Visual Studio (menu „Widok„->”Inne okna„->”Konsola menedżera pakietów„), ale wszystko będzie czarno-białe, co nie jest zbyt wygodne.
Na tym kończę mój artykuł. Jestem pewien, że sam możesz znaleźć opcję dla programu AutoCAD. Mam nadzieję, że prezentowany tutaj materiał znajdzie swoich „klientów”.
Dziękuję za uwagę!
Źródło: www.habr.com