NÀr du utvecklar plugins för CAD-applikationer ( dessa Àr AutoCAD, Revit och Renga) med tiden dyker ett problem upp - nya versioner av program slÀpps, deras API-Àndringar och nya versioner av plugins mÄste göras.
NÀr du bara har ett plugin eller om du fortfarande Àr en sjÀlvlÀrd nybörjare i denna frÄga, kan du helt enkelt göra en kopia av projektet, Àndra nödvÀndiga platser i det och montera en ny version av plugin. Följaktligen kommer efterföljande Àndringar av koden att medföra en multipel ökning av arbetskostnaderna.
NÀr du fÄr erfarenhet och kunskap kommer du att hitta flera sÀtt att automatisera denna process. Jag gick den hÀr vÀgen och jag vill berÀtta vad jag slutade med och hur bekvÀmt det Àr.
LÄt oss först titta pÄ en metod som Àr uppenbar och som jag har anvÀnt lÀnge.
LĂ€nkar till projektfiler
Och för att göra allt enkelt, visuellt och begripligt kommer jag att beskriva allt med hjÀlp av ett abstrakt exempel pÄ pluginutveckling.
LÄt oss öppna Visual Studio (jag har Community 2019-versionen. Och ja - pÄ ryska) och skapa en ny lösning. LÄt oss ringa honom MySuperPluginForRevit
Vi kommer att göra ett plugin för Revit för versionerna 2015-2020. LÄt oss dÀrför skapa ett nytt projekt i lösningen (Net Framework Class Library) och kalla det MySuperPluginForRevit_2015
Vi mÄste lÀgga till lÀnkar till Revit API. Naturligtvis kan vi lÀgga till lÀnkar till lokala filer (vi kommer att behöva installera alla nödvÀndiga SDK:er eller alla versioner av Revit), men vi kommer omedelbart att följa rÀtt vÀg och ansluta NuGet-paketet. Du kan hitta ganska mÄnga paket, men jag kommer att anvÀnda mina egna.
Efter att ha anslutit paketet, högerklicka pÄ objektet "referenser" och vÀlj objektet "Flytta packages.config till PackageReference...»
Om du plötsligt vid denna tidpunkt börjar fÄ panik, eftersom det inte finns nÄgot viktigt objekt i fönstret för paketegenskaper "Kopiera lokalt", som vi definitivt mÄste sÀtta till vÀrdet falsk, fÄ ingen panik - gÄ till mappen med projektet, öppna filen med tillÀgget .csproj i en redigerare som Àr bekvÀm för dig (jag anvÀnder Notepad++) och hitta en post om vÄrt paket dÀr. Hon ser ut sÄ hÀr nu:
<PackageReference Include="ModPlus.Revit.API.2015">
<Version>1.0.0</Version>
</PackageReference>LÀgg till en egenskap till den körning. Det kommer att bli sÄ hÀr:
<PackageReference Include="ModPlus.Revit.API.2015">
<Version>1.0.0</Version>
<ExcludeAssets>runtime</ExcludeAssets>
</PackageReference>Nu, nÀr du bygger ett projekt, kommer filer frÄn paketet inte att kopieras till utdatamappen.
LĂ„t oss gĂ„ vidare - lĂ„t oss omedelbart förestĂ€lla oss att vĂ„rt plugin kommer att anvĂ€nda nĂ„got frĂ„n Revit API, som har förĂ€ndrats över tid nĂ€r nya versioner har slĂ€ppts. Tja, eller sĂ„ behöver vi bara Ă€ndra nĂ„got i koden beroende pĂ„ vilken version av Revit som vi gör insticksprogrammet för. För att lösa sĂ„dana skillnader i kod kommer vi att anvĂ€nda villkorliga kompileringssymboler. Ăppna projektegenskaperna, gĂ„ till fliken "aggregatet"och i fĂ€ltet"Villkorlig kompileringsnotation"lĂ„t oss skriva R2015.
Observera att symbolen mÄste lÀggas till för bÄde Debug- och Release-konfigurationerna.
Tja, medan vi Àr i egenskapsfönstret, gÄr vi omedelbart till fliken "ansökan"och i fÀltet"Standardnamnutrymme» ta bort suffixet _2015sÄ att vÄrt namnomrÄde Àr universellt och oberoende av sammansÀttningens namn:
I mitt fall, i slutprodukten, lĂ€ggs plugins av alla versioner i en mapp, sĂ„ mina sammansĂ€ttningsnamn förblir med formulĂ€rets suffix _20Ń Ń . Men du kan ocksĂ„ ta bort suffixet frĂ„n samlingsnamnet om filerna ska finnas i olika mappar.
LÄt oss gÄ till filkoden Class1.cs och simulera lite kod dÀr, med hÀnsyn till olika versioner 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;
}
}
}Jag tog omedelbart hÀnsyn till alla versioner av Revit ovan version 2015 (som fanns tillgÀngliga i skrivande stund) och tog omedelbart hÀnsyn till förekomsten av villkorliga kompileringssymboler, som skapas med samma mall.
LÄt oss gÄ vidare till huvudhöjdpunkten. Vi skapar ett nytt projekt i vÄr lösning, endast för versionen av plugin för Revit 2016. Vi upprepar alla steg som beskrivs ovan, respektive ersÀtter numret 2015 med numret 2016. Men filen Class1.cs radera frÄn det nya projektet.
Fil med den nödvĂ€ndiga koden - Class1.cs â vi har det redan och vi behöver bara infoga en lĂ€nk till det i ett nytt projekt. Det finns tvĂ„ sĂ€tt att infoga lĂ€nkar:
- LĂ„ng â högerklicka pĂ„ projektet och vĂ€lj "lĂ€gga till»->«Befintligt element", i fönstret som öppnas, hitta den önskade filen och istĂ€llet för alternativet "lĂ€gga till"vĂ€lj alternativet"LĂ€gg till som anslutning»
- kort â direkt i lösningsutforskaren, vĂ€lj önskad fil (eller till och med filer, eller till och med hela mappar) och dra den till ett nytt projekt samtidigt som du hĂ„ller ned Alt-tangenten. NĂ€r du drar kommer du att se att nĂ€r du trycker pĂ„ Alt-tangenten Ă€ndras muspekaren frĂ„n ett plustecken till en pil.
UPD: Jag gjorde lite förvirring i det hÀr stycket - för att överföra flera filer bör du hÄlla nere Skift + Alt!
Efter att ha genomfört proceduren kommer vi att ha en fil i det andra projektet Class1.cs med motsvarande ikon (blÄ pil):
NÀr du redigerar kod i redigeringsfönstret kan du ocksÄ vÀlja vilken projektkontext du vill visa koden i, vilket gör att du kan se koden redigeras under olika villkorliga kompileringssymboler:
Vi skapar alla andra projekt (2017-2020) med detta schema. Life hack - om du drar filer i Solution Explorer inte frÄn basprojektet, utan frÄn projektet dÀr de redan Àr infogade som en lÀnk, behöver du inte hÄlla ned Alt-tangenten!
Det beskrivna alternativet Àr ganska bra fram till ögonblicket för att lÀgga till en ny version av plugin eller tills ögonblicket för att lÀgga till nya filer till projektet - allt detta blir vÀldigt trÄkigt. Och nyligen insÄg jag plötsligt hur man reder ut allt med ett projekt och vi gÄr vidare till den andra metoden
Magin med konfigurationer
NÀr du har lÀst klart hÀr kan du utbrista: "Varför beskrev du den första metoden, om artikeln direkt handlar om den andra?!" Och jag beskrev allt för att göra det tydligare varför vi behöver villkorade kompileringssymboler och pÄ vilka stÀllen vÄra projekt skiljer sig Ät. Och nu blir det tydligare för oss exakt vilka skillnader i projekt vi behöver genomföra, vilket bara lÀmnar ett projekt kvar.
Och för att göra allt mer uppenbart kommer vi inte att skapa ett nytt projekt, utan kommer att göra Àndringar i vÄrt nuvarande projekt som skapats pÄ det första sÀttet.
SĂ„ först och frĂ€mst tar vi bort alla projekt frĂ„n lösningen utom det huvudsakliga (som innehĂ„ller filerna direkt). De dĂ€r. projekt för versioner 2016-2020. Ăppna mappen med lösningen och ta bort mapparna för dessa projekt dĂ€r.
Vi har ett projekt kvar i vĂ„rt beslut - MySuperPluginForRevit_2015. Ăppna dess egenskaper och:
- PÄ fliken "ansökan"ta bort suffixet frÄn sammansÀttningens namn _2015 (det kommer att framgÄ varför senare)
- PÄ fliken "aggregatet» ta bort den villkorliga kompileringssymbolen R2015 frÄn motsvarande fÀlt
Obs: den senaste versionen av Visual Studio har en bugg - symboler för villkorlig kompilering visas inte i fönstret för projektegenskaper, Àven om de Àr tillgÀngliga. Om du upplever detta fel mÄste du ta bort dem manuellt frÄn .csproj-filen. Men vi mÄste fortfarande jobba i det, sÄ lÀs vidare.
Byt namn pÄ projektet i Solution Explorer-fönstret genom att ta bort suffixet _2015 och ta sedan bort projektet frÄn lösningen. Detta Àr nödvÀndigt för att upprÀtthÄlla ordning och kÀnslor hos perfektionister! Vi öppnar mappen för vÄr lösning, byter namn pÄ projektmappen dÀr pÄ samma sÀtt och laddar tillbaka projektet i lösningen.
Ăppna konfigurationshanteraren. amerikansk konfiguration SlĂ€pp i princip kommer det inte att behövas, sĂ„ vi tar bort det. Vi skapar nya konfigurationer med namn som redan Ă€r bekanta för oss R2015, R2016, ..., R2020. Observera att du inte behöver kopiera instĂ€llningar frĂ„n andra konfigurationer och att du inte behöver skapa projektkonfigurationer:
GÄ till mappen med projektet och öppna filen med tillÀgget .csproj i en redigerare som passar dig. Förresten, du kan ocksÄ öppna det i Visual Studio - du mÄste ladda ner projektet och sedan kommer det önskade objektet att finnas i snabbmenyn:
Redigering i Visual Studio Àr till och med att föredra, eftersom redigeraren bÄde justerar och uppmanar.
I filen kommer vi att se elementen â allra högst upp ligger den generella, och sedan kommer förutsĂ€ttningarna. Dessa element anger egenskaperna för projektet nĂ€r det byggs. Det första elementet, som Ă€r utan villkor, stĂ€ller in allmĂ€nna egenskaper, och element med villkor Ă€ndrar följaktligen vissa egenskaper beroende pĂ„ konfigurationerna.
GĂ„ till det gemensamma (första) elementet Fastighetsgrupp och titta pĂ„ fastigheten AssemblyName â det hĂ€r Ă€r namnet pĂ„ församlingen och vi ska ha det utan suffix _2015. Om det finns ett suffix, ta bort det.
Att hitta ett element med ett villkor
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">Vi behöver det inte â vi raderar det.
Element med skick
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">kommer att behövas för att fungera i stadiet av kodutveckling och felsökning. Du kan Àndra dess egenskaper för att passa dina behov - stÀlla in olika utmatningsvÀgar, Àndra villkorliga kompileringssymboler, etc.
LÄt oss nu skapa nya element Fastighetsgrupp för vÄra konfigurationer. I dessa element behöver vi bara stÀlla in fyra egenskaper:
- UtvĂ€gsflöde â utdatamapp. Jag stĂ€ller in standardvĂ€rdet binR20xx
- Definiera konstanter â villkorliga kompileringssymboler. VĂ€rdet bör anges TRACE;R20Ń Ń
- TargetFrameworkVersion â plattformsversion. Olika versioner av Revit API krĂ€ver att olika plattformar anges.
- AssemblyName â sammanstĂ€llningsnamn (dvs filnamn). Du kan skriva det exakta namnet pĂ„ sammansĂ€ttningen, men för mĂ„ngsidighet rekommenderar jag att du skriver vĂ€rdet $(AssemblyName)_20Ń Ń . För att göra detta har vi tidigare tagit bort suffixet frĂ„n sammansĂ€ttningsnamnet
Det viktigaste med alla dessa element Àr att de helt enkelt kan kopieras till andra projekt utan att Àndra dem alls. Senare i artikeln kommer jag att bifoga allt innehÄll i .csproj-filen.
Okej, vi har tagit reda pĂ„ projektets egenskaper - det Ă€r inte svĂ„rt. Men vad ska man göra med plugin-bibliotek (NuGet-paket). Om vi ââtittar vidare kommer vi att se att de inkluderade biblioteken Ă€r specificerade i elementen . Men otur - detta element behandlar villkoren felaktigt som ett element Fastighetsgrupp. Kanske Ă€r detta till och med ett Visual Studio-fel, men om du anger flera element Artikelgrupp med konfigurationsvillkor, och infoga olika lĂ€nkar till NuGet-paket inuti, sedan nĂ€r du Ă€ndrar konfigurationen kopplas alla angivna paket till projektet.
Elementet kommer till vÄr hjÀlp , som fungerar enligt vÄr vanliga logik om dÄ annars.
AnvĂ€nder element VĂ€lja, stĂ€ller vi in ââolika NuGet-paket för olika konfigurationer:
Allt innehÄll 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>Observera att i ett av villkoren angav jag tvÄ konfigurationer via ELLER. PÄ sÄ sÀtt kommer det nödvÀndiga paketet att anslutas under konfigurationen Felsök.
Och hÀr har vi nÀstan allt perfekt. Vi laddar tillbaka projektet, aktiverar den konfiguration vi behöver, anropar objektet " i snabbmenyn för lösningen (inte projektet)à terstÀll alla NuGet-paket"och vi ser hur vÄra paket förÀndras.
Och i detta skede kom jag till en ÄtervÀndsgrÀnd - för att samla alla konfigurationer pÄ en gÄng kunde vi anvÀnda batchmontering (meny "aggregatet»->«Batchbyggd"), men nÀr du byter konfigurationer ÄterstÀlls inte paket automatiskt. Och nÀr man monterar projektet hÀnder inte heller detta, Àven om det i teorin borde göra det. Jag har inte hittat en lösning pÄ detta problem med standardmetoder. Och troligtvis Àr detta ocksÄ en Visual Studio-bugg.
DĂ€rför, för batchmontering, beslutades det att anvĂ€nda ett speciellt automatiserat monteringssystem . Jag ville faktiskt inte ha det hĂ€r eftersom jag tycker att det Ă€r överdrivet vad gĂ€ller pluginutveckling, men för tillfĂ€llet ser jag ingen annan lösning. Och till frĂ„gan "Varför Nuke?" Svaret Ă€r enkelt â vi anvĂ€nder det pĂ„ jobbet.
SĂ„, gĂ„ till mappen för vĂ„r lösning (inte projektet), hĂ„ll ner tangenten shift och högerklicka pĂ„ ett tomt utrymme i mappen - i snabbmenyn vĂ€lj objektet "Ăppna PowerShell-fönstret hĂ€r".
Om du inte har det installerat nuke, skriv sedan först kommandot
dotnet tool install Nuke.GlobalTool âglobalSkriv nu kommandot nuke och du kommer att bli ombedd att konfigurera nuke för det aktuella projektet. Jag vet inte hur man skriver det hĂ€r mer korrekt pĂ„ ryska - pĂ„ engelska kommer det att skrivas. Kunde inte hitta .nuke-filen. Vill du sĂ€tta upp en build? [y/n]
Tryck pÄ Y-tangenten och sedan kommer det att finnas direktinstÀllningar. Vi behöver det enklaste alternativet att anvÀnda MSBuild, sÄ vi svarar som pÄ skÀrmdumpen:
LÄt oss gÄ till Visual Studio, som kommer att uppmana oss att ladda om lösningen, eftersom ett nytt projekt har lagts till den. Vi laddar om lösningen och ser att vi har ett projekt SLUTRESULTAT dÀr vi bara Àr intresserade av en fil - Build.cs
Ăppna den hĂ€r filen och skriv ett skript för att bygga projektet för alla konfigurationer. Tja, eller anvĂ€nd mitt skript, som du kan redigera för att passa dina 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 ÄtervÀnder till PowerShell-fönstret och skriver kommandot igen nuke (du kan skriva kommandot nuke anger vad som krÀvs MÄlet. Men vi har en MÄlet, som körs som standard). Efter att ha tryckt pÄ Enter-tangenten kommer vi att kÀnna oss som riktiga hackare, eftersom vÄrt projekt, som i en film, automatiskt kommer att sammanstÀllas för olika konfigurationer.
Förresten, du kan anvÀnda PowerShell direkt frÄn Visual Studio (meny "Visa»->«Andra fönster»->«Package Manager Console"), men allt kommer att vara i svart och vitt, vilket inte Àr sÀrskilt bekvÀmt.
Detta avslutar min artikel. Jag Àr sÀker pÄ att du kan ta reda pÄ alternativet för AutoCAD sjÀlv. Jag hoppas att materialet som presenteras hÀr kommer att hitta sina "kunder".
Tack för din uppmÀrksamhet!
KĂ€lla: will.com