Rozšiřitelnost systému projektů visual Studio C++ a integrace sady nástrojů
Systém projektů Visual C++ se používá pro .vcxproj soubory. Je založená na sadě Visual Studio Common Project System (CPS) a poskytuje další body rozšiřitelnosti specifické pro C++ pro snadnou integraci nových sad nástrojů, sestavení architektur a cílových platforem.
Struktura cílů nástroje C++ MSBuild
Všechny soubory .vcxproj naimportují tyto soubory:
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.props" />
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" />
Tyto soubory definují samy o sobě. Místo toho importují další soubory na základě těchto hodnot vlastností:
$(ApplicationType)
Příklady: Windows Store, Android, Linux
$(ApplicationTypeRevision)
Musí se jednat o platný řetězec verze ve formátu major.minor[.build[.revision]].
Příklady: 1.0, 10.0.0.0
$(Platform)
Architektura sestavení s názvem "Platforma" z historických důvodů.
Příklady: Win32, x86, x64, ARM
$(PlatformToolset)
Příklady: v140, v141, v141_xp, llvm
Tyto hodnoty vlastností určují názvy složek v $(VCTargetsPath)
kořenové složce:
$(VCTargetsPath)
\
typ aplikace\
$(ApplicationType)
\
$(ApplicationTypeRevision)
\
Platformy\
$(Platform)
\
PlatformToolsets\
$(PlatformToolset)
Platformy\
$(Platform)
\
PlatformToolsets\
$(PlatformToolset)
Složka $(VCTargetsPath)
\Platforms\ se používá, pokud $(ApplicationType)
je prázdná pro desktopové projekty Windows.
Přidání nové sady nástrojů platformy
Pokud chcete přidat novou sadu nástrojů, například "MyToolset" pro existující platformu Win32, vytvořte složku MyToolset v části $(VCTargetsPath)
\Platforms\Win32\PlatformToolsets\a vytvořte v ní soubory Toolset.props a Toolset.targets.
Každý název složky v části PlatformToolsets se zobrazí v dialogovém okně Vlastnosti projektu jako dostupná sada nástrojů platformy pro zadanou platformu, jak je znázorněno zde:
Vytvořte podobné složky MyToolset a soubory Toolset.props a Toolset.targets v každé existující složce platformy podporuje tato sada nástrojů.
Přidání nové platformy
Pokud chcete přidat novou platformu, například MyPlatform, vytvořte složku MyPlatform ve $(VCTargetsPath)
složce Platformy a vytvořte v ní soubory Platform.default.props, Platform.props a Platform.targets . $(VCTargetsPath)
Vytvořte také složku \Platforms\MyPlatform\PlatformToolsets\ a vytvořte v ní alespoň jednu sadu nástrojů.
Všechny názvy složek ve složce Platformy pro každý z nich $(ApplicationType)
se $(ApplicationTypeRevision)
zobrazí v integrovaném vývojovém prostředí jako dostupné možnosti platformy pro projekt.
Přidání nového typu aplikace
Pokud chcete přidat nový typ aplikace, vytvořte složku MyApplicationType v části $(VCTargetsPath)
\Typ aplikace\ a vytvořte v ní soubor Defaults.props. Nejméně jedna revize je vyžadována pro typ aplikace, takže také vytvořte $(VCTargetsPath)
složku \Typ aplikace\MyApplicationType\1.0 a vytvořte v ní soubor Defaults.props . Měli byste také vytvořit $(VCTargetsPath)
složku \ApplicationType\MyApplicationType\1.0\Platforms a vytvořit v ní alespoň jednu platformu.
$(ApplicationType)
a $(ApplicationTypeRevision)
vlastnosti nejsou viditelné v uživatelském rozhraní. Jsou definovány v šablonách projektu a po vytvoření projektu je nelze změnit.
Strom importu .vcxproj
Zjednodušený stromimportch
$(VCTargetsPath)
\Microsoft.Cpp.Default.props
$(MSBuildExtensionsPath)
\$(MSBuildToolsVersion)
\Microsoft.Common.props
$(VCTargetsPath)
\ImportBefore\Default\*.rekvizity
$(VCTargetsPath)
\Typ\\$(ApplicationType)
aplikace Default.props
$(VCTargetsPath)
\Typ$(ApplicationTypeRevision)
\$(ApplicationType)
\\aplikace Default.props
$(VCTargetsPath)
\Platformy\\$(Platform)
typů$(ApplicationType)
\\$(ApplicationTypeRevision)
\aplikací Platform.default.props
$(VCTargetsPath)
\ImportAfter\Default\*.rekvizity
Desktopové projekty Windows nedefinují $(ApplicationType)
, takže importují jenom
$(VCTargetsPath)
\Microsoft.Cpp.Default.props
$(MSBuildExtensionsPath)
\$(MSBuildToolsVersion)
\Microsoft.Common.props
$(VCTargetsPath)
\ImportBefore\Default\*.rekvizity
$(VCTargetsPath)
\Platform.default.props\$(Platform)
\
$(VCTargetsPath)
\ImportAfter\Default\*.rekvizity
Tuto vlastnost použijeme $(_PlatformFolder)
k uložení $(Platform)
umístění složek platformy. Tato vlastnost je
$(VCTargetsPath)
\Platformy\$(Platform)
pro desktopové aplikace pro Windows a
$(VCTargetsPath)
\Platformy typů\\$(ApplicationType)
\$(ApplicationTypeRevision)
aplikací\$(Platform)
pro všechno ostatní.
Soubory props se naimportují v tomto pořadí:
$(VCTargetsPath)
\Microsoft.Cpp.props
$(_PlatformFolder)
\Platform.props
$(VCTargetsPath)
\Microsoft.Cpp.Platform.props
$(_PlatformFolder)
\ImportBefore\*.rekvizity
$(_PlatformFolder)
\PlatformToolsets\\$(PlatformToolset)
Toolset.props
$(_PlatformFolder)
\ImportAfter\*.rekvizity
Cílové soubory se naimportují v tomto pořadí:
$(VCTargetsPath)
\Microsoft.Cpp.targets
$(VCTargetsPath)
\Microsoft.Cpp.Current.targets
$(_PlatformFolder)
\Platform.targets
$(VCTargetsPath)
\Microsoft.Cpp.Platform.targets
$(_PlatformFolder)
\ImportBefore\*.cíle
$(_PlatformFolder)
\PlatformToolsets\\$(PlatformToolset)
Toolset.target
$(_PlatformFolder)
\ImportAfter\*.cíle
Pokud potřebujete definovat některé výchozí vlastnosti sady nástrojů, můžete přidat soubory do příslušných složek ImportBefore a ImportAfter.
Soubory Author Toolset.props a Toolset.targets
Soubory Toolset.props a Toolset.targets mají úplnou kontrolu nad tím, co se stane při sestavování při použití této sady nástrojů. Můžou také řídit dostupné ladicí programy, některé uživatelské rozhraní IDE, například obsah v dialogovém okně Stránky vlastností, a některé další aspekty chování projektu.
I když sada nástrojů může přepsat celý proces sestavení, obvykle jen chcete, aby sada nástrojů upravila nebo přidala některé kroky sestavení nebo používala jiné nástroje sestavení jako součást existujícího procesu sestavení. K dosažení tohoto cíle existuje řada běžných props a cílů souborů, které může sada nástrojů importovat. V závislosti na tom, co chcete, aby sada nástrojů dělala, můžou být tyto soubory užitečné použít jako importy nebo jako příklady:
$(VCTargetsPath)
\Microsoft.CppCommon.targetsTento soubor definuje hlavní části nativního procesu sestavení a také importuje:
$(VCTargetsPath)
\Microsoft.CppBuild.targets$(VCTargetsPath)
\Microsoft.BuildSteps.targets$(MSBuildToolsPath)
\Microsoft.Common.Targets
$(VCTargetsPath)
\Microsoft.Cpp.Common.propsNastaví výchozí hodnoty sad nástrojů, které používají kompilátory Microsoftu a cílová okna.
$(VCTargetsPath)
\Microsoft.Cpp.WindowsSDK.propsTento soubor určuje umístění sady Windows SDK a definuje některé důležité vlastnosti pro aplikace, které cílí na Windows.
Integrace cílů specifických pro sadu nástrojů s výchozím procesem sestavení jazyka C++
Výchozí proces sestavení jazyka C++ je definován v microsoft.CppCommon.targets. Cíle, které neexistují, volají žádné konkrétní nástroje sestavení; určí hlavní kroky sestavení, jejich pořadí a závislosti.
Sestavení C++ má tři hlavní kroky, které jsou reprezentovány následujícími cíli:
BuildGenerateSources
BuildCompile
BuildLink
Vzhledem k tomu, že každý krok sestavení může být spuštěn nezávisle, cíle spuštěné v jednom kroku nemůžou spoléhat na skupiny položek a vlastnosti definované v cílech, které běží jako součást jiného kroku. Toto dělení umožňuje určité optimalizace výkonu sestavení. I když se ve výchozím nastavení nepoužívá, stále se doporučuje, abyste toto oddělení respektovali.
Cíle, které se spouští uvnitř každého kroku, jsou řízeny těmito vlastnostmi:
$(BuildGenerateSourcesTargets)
$(BuildCompileTargets)
$(BeforeBuildLinkTargets)
Každý krok má také vlastnosti Before a After.
<Target
Name="_BuildGenerateSourcesAction"
DependsOnTargets="$(CommonBuildOnlyTargets);$(BeforeBuildGenerateSourcesTargets);$(BuildGenerateSourcesTargets);$(AfterBuildGenerateSourcesTargets)" />
<Target
Name="\_BuildCompileAction"
DependsOnTargets="$(CommonBuildOnlyTargets);$(BeforeBuildCompileTargets);$(BuildCompileTargets);$(AfterBuildCompileTargets)" />
<Target
Name="\_BuildLinkAction"
DependsOnTargets="$(CommonBuildOnlyTargets);$(BeforeBuildLinkTargets);$(BuildLinkTargets);$(AfterBuildLinkTargets)" />
Příklady cílů zahrnutých v jednotlivých krocích najdete v souboru Microsoft.CppBuild.targets :
<BuildCompileTargets Condition="'$(ConfigurationType)'\!='Utility'">
$(BuildCompileTargets);
_ClCompile;
_ResGen;
_ResourceCompile;
$(BuildLibTargets);
</BuildCompileTargets>
Pokud se podíváte na cíle, například _ClCompile
, uvidíte, že nedělají nic přímo sami, ale místo toho závisí na jiných cílech, včetně ClCompile
:
<Target Name="_ClCompile"
DependsOnTargets="$(BeforeClCompileTargets);$(ComputeCompileInputsTargets);MakeDirsForCl;ClCompile;$(AfterClCompileTargets)" >
</Target>
ClCompile
a další cíle specifické pro nástroj sestavení jsou definovány jako prázdné cíle v Microsoft.CppBuild.targets:
<Target Name="ClCompile"/>
ClCompile
Protože cíl je prázdný, pokud ho nepřepíše sada nástrojů, neprovádí se žádná skutečná akce sestavení. Cíle sady nástrojů mohou přepsat ClCompile
cíl, to znamená, že po importu Microsoft.CppBuild.targets mohou obsahovat jinou ClCompile
definici:
<Target Name="ClCompile"
Condition="'@(ClCompile)' != ''"
DependsOnTargets="SelectClCompile">
<!-- call some MSBuild tasks -->
</Target>
I přes jeho název, který byl vytvořen před implementací podpory multiplatformní sady Visual Studio, ClCompile
nemusí cíl volat CL.exe. Může také volat Clang, gcc nebo jiné kompilátory pomocí příslušných úloh MSBuild.
Cíl ClCompile
by neměl obsahovat žádné závislosti s výjimkou SelectClCompile
cíle, který je nutný pro jeden příkaz kompilace souboru pro práci v integrovaném vývojovém prostředí( IDE).
Úlohy nástroje MSBuild pro použití v cílech sady nástrojů
Chcete-li vyvolat skutečný nástroj sestavení, cíl musí volat úlohu MSBuild. Existuje základní úloha Exec, která umožňuje zadat příkazový řádek ke spuštění. Nástroje sestavení ale obvykle mají mnoho možností, vstupů a výstupů ke sledování přírůstkových sestavení, takže je pro ně vhodnější mít speciální úlohy. Úloha například CL
přeloží vlastnosti NÁSTROJE MSBuild do CL.exe přepínačů, zapíše je do souboru odpovědi a volá CL.exe. Sleduje také všechny vstupní a výstupní soubory pro pozdější přírůstkové sestavení. Další informace najdete v tématu Přírůstkové sestavení a aktuální kontroly.
Microsoft.Cpp.Common.Tasks.dll implementuje tyto úlohy:
BSCMake
CL
ClangCompile
(přepínače clang-gcc)LIB
LINK
MIDL
Mt
RC
XDCMake
CustomBuild
(například Exec, ale se vstupním a výstupním sledováním)SetEnv
GetOutOfDateItems
Pokud máte nástroj, který provádí stejnou akci jako existující nástroj a má podobné přepínače příkazového řádku (jako clang-cl a CL), můžete pro oba nástroje použít stejnou úlohu.
Pokud potřebujete vytvořit novou úlohu pro nástroj sestavení, můžete si vybrat z následujících možností:
Pokud tuto úlohu používáte zřídka nebo pokud na sestavení nezáleží několik sekund, můžete použít vložené úlohy nástroje MSBuild:
Úloha Xaml (vlastní pravidlo sestavení)
Příklad deklarace úlohy Xaml naleznete v tématu
$(VCTargetsPath)
\BuildCustomizations\masm.xml a pro jeho použití viz$(VCTargetsPath)
\BuildCustomizations\masm.targets.
Pokud chcete dosáhnout lepšího výkonu úloh nebo potřebujete jenom složitější funkce, použijte běžný proces zápisu úloh NÁSTROJE MSBuild.
Pokud nejsou všechny vstupy a výstupy nástroje uvedeny na příkazovém řádku nástroje, jako v
CL
,MIDL
aRC
případy, a pokud chcete automatické sledování vstupních a výstupních souborů a vytvoření souboru .tlog, odvozte úlohu zMicrosoft.Build.CPPTasks.TrackedVCToolTask
třídy. V současné době existuje dokumentace pro základní třídu ToolTask , neexistují žádné příklady ani dokumentace pro podrobnostiTrackedVCToolTask
třídy. Pokud by to mělo zvláštní zájem, přidejte svůj hlas na žádost komunity vývojářů.
Přírůstkové sestavení a aktuální kontroly
Výchozí cíle přírůstkového sestavení NÁSTROJE MSBuild používají Inputs
a Outputs
atributy. Pokud je zadáte, NÁSTROJ MSBuild volá cíl pouze v případě, že některý ze vstupů má novější časové razítko než všechny výstupy. Vzhledem k tomu, že zdrojové soubory často zahrnují nebo importují jiné soubory a nástroje sestavení vytvářejí různé výstupy v závislosti na možnostech nástroje, je obtížné určit všechny možné vstupy a výstupy v cílech NÁSTROJE MSBuild.
Ke správě tohoto problému používá sestavení C++ jinou techniku pro podporu přírůstkových sestavení. Většina cílů nezadá vstupy a výstupy a v důsledku toho se vždy spustí během sestavení. Úlohy volané cíli zapisují informace o všech vstupech a výstupech do souborů tlog , které mají příponu .tlog. Soubory .tlog se používají v pozdějších buildech ke kontrole toho, co se změnilo a co je potřeba znovu vytvořit a co je aktuální. Soubory .tlog jsou také jediným zdrojem pro výchozí aktuální kontrolu sestavení integrovaného vývojového prostředí (IDE).
Chcete-li určit všechny vstupy a výstupy, nativní úlohy nástroje používají tracker.exe a FileTracker třídy poskytované MSBuild.
Microsoft.Build.CPPTasks.Common.dll definuje TrackedVCToolTask
veřejnou abstraktní základní třídu. Většina úloh nativních nástrojů je odvozena z této třídy.
Počínaje verzí Visual Studio 2017 update 15.8 můžete pomocí GetOutOfDateItems
úlohy implementované v Microsoft.Cpp.Common.Tasks.dll vytvořit soubory .tlog pro vlastní cíle se známými vstupy a výstupy.
Případně je můžete vytvořit pomocí WriteLinesToFile
úkolu. _WriteMasmTlogs
Jako příklad si můžete prohlédnout cíl v $(VCTargetsPath)
\souboru BuildCustomizations\masm.targets.
Soubory .tlog
Existují tři typy souborů .tlog: čtení, zápis a příkazový řádek. Soubory .tlog pro čtení a zápis se používají přírůstkovými sestaveními a aktuální kontrolou integrovaného vývojového prostředí (IDE). Soubory .tlog příkazového řádku se používají pouze v přírůstkových buildech.
NÁSTROJ MSBuild poskytuje tyto pomocné třídy pro čtení a zápis souborů .tlog:
FlatTrackingData třídy lze použít pro přístup ke čtení i zápisu souborů .tlog a identifikovat vstupy, které jsou novější než výstupy, nebo pokud chybí výstup. Používá se v aktuální kontrole.
Soubory .tlog příkazového řádku obsahují informace o příkazovýchřádch Používají se pouze pro přírůstkové sestavení, ne aktuální kontroly, takže interní formát je určen úlohou MSBuild, která je vytváří.
Čtení formátu .tlog
Čtení souborů .tlog (*.read.*.tlog) obsahuje informace o zdrojových souborech a jejich závislostech.
Stříšku (^) na začátku řádku označuje jeden nebo více zdrojů. Zdroje, které sdílejí stejné závislosti, jsou oddělené svislým pruhem (|).
Soubory závislostí jsou uvedeny za zdroji, každý na vlastním řádku. Všechny názvy souborů jsou úplné cesty.
Předpokládejme například, že se zdroje projektu nacházejí v F:\test\ConsoleApplication1\ConsoleApplication1. Pokud váš zdrojový soubor Class1.cpp obsahuje tyto položky:
#include "stdafx.h" //precompiled header
#include "Class1.h"
pak soubor CL.read.1.tlog obsahuje zdrojový soubor následovaný jeho dvěma závislostmi:
^F:\TEST\CONSOLEAPPLICATION1\CONSOLEAPPLICATION1\CLASS1.CPP
F:\TEST\CONSOLEAPPLICATION1\CONSOLEAPPLICATION1\DEBUG\CONSOLEAPPLICATION1.PCH
F:\TEST\CONSOLEAPPLICATION1\CONSOLEAPPLICATION1\CLASS1.H
Pro některé nástroje není nutné psát názvy souborů velkými písmeny, ale je to pro některé nástroje praktické.
Zápis formátu .tlog
Zapisovat soubory .tlog (*.write.*.tlog) připojují zdroje a výstupy.
Stříšku (^) na začátku řádku označuje jeden nebo více zdrojů. Více zdrojů je odděleno svislým pruhem (|).
Výstupní soubory vytvořené ze zdrojů by měly být uvedeny za zdroji, a to každý na vlastním řádku. Všechny názvy souborů musí být úplné cesty.
Například pro jednoduchý projekt ConsoleApplication, který má další zdrojový soubor Class1.cpp, může soubor link.write.1.tlog obsahovat:
^F:\TEST\CONSOLEAPPLICATION1\CONSOLEAPPLICATION1\DEBUG\CLASS1.OBJ|F:\TEST\CONSOLEAPPLICATION1\CONSOLEAPPLICATION1\DEBUG\CONSOLEAPPLICATION1.OBJ|F:\TEST\CONSOLEAPPLICATION1\CONSOLEAPPLICATION1\DEBUG\STDAFX.OBJ
F:\TEST\CONSOLEAPPLICATION1\DEBUG\CONSOLEAPPLICATION1.ILK
F:\TEST\CONSOLEAPPLICATION1\DEBUG\CONSOLEAPPLICATION1.EXE
F:\TEST\CONSOLEAPPLICATION1\DEBUG\CONSOLEAPPLICATION1.PDB
Sestavení v době návrhu
V integrovaném vývojovém prostředí .vcxproj projekty používají sadu cílů MSBuild k získání dalších informací z projektu a k opětovnému vygenerování výstupních souborů. Některé z těchto cílů se používají pouze v sestaveních v době návrhu, ale mnoho z nich se používá jak v pravidelných buildech, tak v sestaveních v době návrhu.
Obecné informace o sestaveních v době návrhu najdete v dokumentaci CPS k sestavením v době návrhu. Tato dokumentace se vztahuje pouze částečně na projekty Visual C++.
Compile
Cíle CompileDesignTime
uvedené v dokumentaci k sestavením v době návrhu se nikdy nespouštějí pro projekty .vcxproj. Projekty jazyka Visual C++ .vcxproj používají k získání informací IntelliSense různé cíle v době návrhu.
Cíle doby návrhu pro informace technologie IntelliSense
Cíle doby návrhu používané v projektech .vcxproj jsou definovány v $(VCTargetsPath)
\microsoft.Cpp.DesignTime.targets.
Cíl GetClCommandLines
shromažďuje možnosti kompilátoru pro IntelliSense:
<Target
Name="GetClCommandLines"
Returns="@(ClCommandLines)"
DependsOnTargets="$(DesignTimeBuildInitTargets);$(ComputeCompileInputsTargets)">
DesignTimeBuildInitTargets
– pouze cíle v době návrhu, které jsou vyžadovány pro inicializaci sestavení v době návrhu. Mimo jiné tyto cíle zakazují některé z běžných funkcí sestavení, aby se zlepšil výkon.ComputeCompileInputsTargets
– sada cílů, které mění možnosti a položky kompilátoru. Tyto cíle běží v době návrhu i v pravidelných buildech.
Cíl volá CLCommandLine
úlohu, která vytvoří příkazový řádek, který se použije pro IntelliSense. I přes jeho název může zpracovávat nejen možnosti CL, ale také možnosti Clang a gcc. Typ přepínačů kompilátoru je řízen ClangMode
vlastností.
V současné době příkazový řádek vytvořený úlohou CLCommandLine
vždy používá přepínače CL (i v režimu Clang), protože je pro modul IntelliSense jednodušší parsovat.
Pokud přidáváte cíl, který se spouští před kompilací, ať už se jedná o běžnou dobu nebo čas návrhu, ujistěte se, že nepřeruší sestavení v době návrhu nebo nemá vliv na výkon. Nejjednodušším způsobem, jak otestovat cíl, je otevřít příkazový řádek pro vývojáře a spustit tento příkaz:
msbuild /p:SolutionDir=*solution-directory-with-trailing-backslash*;Configuration=Debug;Platform=Win32;BuildingInsideVisualStudio=true;DesignTimebuild=true /t:\_PerfIntellisenseInfo /v:d /fl /fileloggerparameters:PerformanceSummary \*.vcxproj
Tento příkaz vytvoří podrobný protokol sestavení msbuild.log, který obsahuje souhrn výkonu cílů a úkolů na konci.
Ujistěte se, že se používá Condition ="'$(DesignTimeBuild)' != 'true'"
ve všech operacích, které mají smysl pouze pro běžné sestavení, a ne pro sestavení v době návrhu.
Cíle v době návrhu, které generují zdroje
Tato funkce je ve výchozím nastavení zakázaná pro nativní projekty Desktopu a v současné době není podporována u projektů uložených v mezipaměti.
Pokud GeneratorTarget
jsou pro položku projektu definována metadata, cíl se spustí automaticky při načtení projektu i při změně zdrojového souboru.
Pokud například chcete automaticky generovat soubory .cpp nebo .h ze souborů .xaml, $(VSInstallDir)
\definují soubory MSBuild\Microsoft\WindowsXaml\v16.0\*\Microsoft.Windows.UI.Xaml.CPP.Targets tyto entity:
<ItemDefinitionGroup>
<Page>
<GeneratorTarget>DesignTimeMarkupCompilation</GeneratorTarget>
</Page>
<ApplicationDefinition>
<GeneratorTarget>DesignTimeMarkupCompilation</GeneratorTarget>
</ApplicationDefinition>
</ItemDefinitionGroup>
<Target Name="DesignTimeMarkupCompilation">
<!-- BuildingProject is used in Managed builds (always true in Native) -->
<!-- DesignTimeBuild is used in Native builds (always false in Managed) -->
<CallTarget Condition="'$(BuildingProject)' != 'true' Or $(DesignTimeBuild) == 'true'" Targets="DesignTimeMarkupCompilationCT" />
</Target>
Task.HostObject
Chcete-li získat neuložené obsah zdrojových souborů, cíle a úkol by měly být registrovány jako MsbuildHostObjects pro dané projekty v pkgdef:
\[$RootKey$\\Projects\\{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}\\MSBuildHostObjects\]
\[$RootKey$\\Projects\\{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}\\MSBuildHostObjects\\DesignTimeMarkupCompilationCT;CompileXaml\]
@="{83046B3F-8984-444B-A5D2-8029DEE2DB70}"
Rozšiřitelnost projektu Visual C++ v integrovaném vývojovém prostředí sady Visual Studio
Systém projektů Visual C++ je založený na systému projektů VS a používá jeho body rozšiřitelnosti. Implementace hierarchie projektů je ale specifická pro Visual C++ a není založená na cpS, takže rozšiřitelnost hierarchie je omezená na položky projektu.
Stránky vlastností projektu
Obecné informace o návrhu naleznete v tématu Cílení na více architektur pro projekty VC++.
Stránky vlastností, které vidíte v dialogovém okně Vlastnosti projektu pro projekt projektu, jsou definovány soubory pravidel . Soubor pravidla určuje sadu vlastností, které se mají zobrazit na stránce vlastností a jak a kde mají být uloženy v souboru projektu. Soubory pravidel jsou .xml soubory, které používají formát Xaml. Typy používané k serializaci jsou popsány v Microsoft.Build.Framework.XamlTypes. Další informace o použití souborů pravidel v projektech naleznete v tématu Soubory pravidel stránky vlastností XML soubory pravidel.
Soubory pravidel musí být přidány do PropertyPageSchema
skupiny položek:
<ItemGroup>
<PropertyPageSchema Include="$(VCTargetsPath)$(LangID)\general.xml;"/>
<PropertyPageSchema Include="$(VCTargetsPath)$(LangID)\general_file.xml">
<Context>File</Context>
</PropertyPageSchema>
</ItemGroup>
Context
metadata omezují viditelnost pravidel, která je také řízena typem pravidla a může mít jednu z těchto hodnot:
Project
| File
| PropertySheet
CPS podporuje jiné hodnoty pro typ kontextu, ale nepoužívají se v projektech Visual C++.
Pokud by pravidlo mělo být viditelné ve více než jednom kontextu, oddělte kontextové hodnoty středníky (;), jak je znázorněno tady:
<PropertyPageSchema Include="$(MyFolder)\MyRule.xml">
<Context>Project;PropertySheet</Context>
</PropertyPageSchema>
Formát pravidla a hlavní typy
Formát pravidla je jednoduchý, takže tato část popisuje pouze atributy, které ovlivňují vzhled pravidla v uživatelském rozhraní.
<Rule
Name="ConfigurationGeneral"
DisplayName="General"
PageTemplate="generic"
Description="General"
xmlns="http://schemas.microsoft.com/build/2009/properties">
Atribut PageTemplate
definuje způsob zobrazení pravidla v dialogovém okně Stránky vlastností. Atribut může mít jednu z těchto hodnot:
Atribut | Popis |
---|---|
generic |
Všechny vlastnosti se zobrazují na jedné stránce pod nadpisy Kategorie. Pravidlo může být viditelné pro Project kontexty PropertySheet , ale ne File .Příklad: $(VCTargetsPath) \1033\general.xml |
tool |
Kategorie se zobrazují jako podstránky. Pravidlo lze zobrazit ve všech kontextech: Project PropertySheet a File .Pravidlo je viditelné ve vlastnostech projektu pouze v případě, že projekt obsahuje položky s definovaným ItemType v Rule.DataSource , pokud není název pravidla zahrnut do ProjectTools skupiny položek.Příklad: $(VCTargetsPath) \1033\clang.xml |
debugger |
Stránka se zobrazí jako součást stránky Ladění. Kategorie se v současné době ignorují. Název pravidla by se měl shodovat s atributem objektu ExportDebugger MEF pro ladění.Příklad: $(VCTargetsPath) \1033\debugger_local_windows.xml |
custom | Vlastní šablona. Název šablony by měl odpovídat ExportPropertyPageUIFactoryProvider atributu objektu PropertyPageUIFactoryProvider MEF. Viz Microsoft.VisualStudio.ProjectSystem.Designers.Properties.IPropertyPageUIFactoryProvider.Příklad: $(VCTargetsPath) \1033\userMacros.xml |
Pokud pravidlo používá některou ze šablon založených na objektu Property Grid, může pro své vlastnosti použít tyto body rozšiřitelnosti:
Rozšíření pravidla
Pokud chcete použít existující pravidlo, ale potřebujete přidat nebo odebrat (tj. skrýt) jenom několik vlastností, můžete vytvořit pravidlo rozšíření.
Přepsání pravidla
Možná chcete, aby sada nástrojů používala většinu výchozích pravidel projektu, ale nahradila jenom jednu nebo několik z nich. Řekněme například, že chcete změnit pouze pravidlo C/C++ tak, aby zobrazoval různé přepínače kompilátoru. Můžete zadat nové pravidlo se stejným názvem a zobrazovaným názvem jako existující pravidlo a zahrnout ho do PropertyPageSchema
skupiny položek po importu výchozích cílů cpp. V projektu se používá pouze jedno pravidlo s daným názvem a poslední pravidlo zahrnuté do PropertyPageSchema
skupiny položek vyhraje.
Položky projektu
Soubor ProjectItemsSchema.xml definuje ContentType
a ItemType
hodnoty položek, které jsou považovány za položky projektu, a definuje FileExtension
prvky, které určují, do které skupiny položek se přidá nový soubor.
Výchozí soubor ProjectItemsSchema se nachází v $(VCTargetsPath)
\ProjectItemsSchema.xml 1033.\ Pokud ho chcete rozšířit, musíte vytvořit soubor schématu s novým názvem, například MyProjectItemsSchema.xml:
<ProjectSchemaDefinitions xmlns="http://schemas.microsoft.com/build/2009/properties">
<ItemType Name="MyItemType" DisplayName="C/C++ compiler"/>
<ContentType
Name="MyItems"
DisplayName="My items"
ItemType=" MyItemType ">
</ContentType>
<FileExtension Name=".abc" ContentType=" MyItems"/>
</ProjectSchemaDefinitions>
Pak do souboru cílů přidejte:
<ItemGroup>
<PropertyPageSchema Include="MyProjectItemsSchema.xml"/>
</ItemGroup>
Příklad: $(VCTargetsPath)
\BuildCustomizations\masm.xml
Ladící programy
Ladicí služba v sadě Visual Studio podporuje rozšiřitelnost pro ladicí modul. Další informace najdete v těchto ukázkách:
Chcete-li zadat ladicí moduly a další vlastnosti pro ladicí relaci, musíte implementovat komponentu Debug Launcher MEF a přidat debugger
pravidlo. Příklad najdete v $(VCTargetsPath)
souboru \1033\debugger_local_windows.xml.
Nasadit
.vcxproj projekty používají rozšiřitelnost systému projektů sady Visual Studio pro zprostředkovatele nasazení.
Kontrola aktuálního stavu
Ve výchozím nastavení vyžaduje kontrola aktuálního sestavení čtení souborů .tlog a zápis souborů .tlog do $(TlogLocation)
složky během sestavování pro všechny vstupy a výstupy sestavení.
Použití vlastní aktuální kontroly:
Zakažte výchozí aktuální kontrolu přidáním
NoVCDefaultBuildUpToDateCheckProvider
funkce do souboru Toolset.targets :<ItemGroup> <ProjectCapability Include="NoVCDefaultBuildUpToDateCheckProvider" /> </ItemGroup>
Implementujte vlastní IBuildUpToDateCheckProvider.
Upgrade projektu
Výchozí upgrade projektu .vcxproj
Výchozí .vcxproj upgrade projektu změní PlatformToolset
verzi sady nástrojů MSBuild ApplicationTypeRevision
a rozhraní .NET Framework. Poslední dva se vždy změní na výchozí verze sady Visual Studio, ale PlatformToolset
ApplicationTypeRevision
lze je řídit speciálními vlastnostmi NÁSTROJE MSBuild.
Upgrader používá tato kritéria k rozhodnutí, jestli je možné projekt upgradovat, nebo ne:
Pro projekty, které definují
ApplicationType
aApplicationTypeRevision
, existuje složka s vyšším číslem revize než aktuální.Vlastnost
_UpgradePlatformToolsetFor_<safe_toolset_name>
je definována pro aktuální sadu nástrojů a její hodnota není rovna aktuální sadě nástrojů.V těchto názvech <vlastností safe_toolset_name> představuje název sady nástrojů se všemi nealnumerickými znaky nahrazenými podtržítkem (_).
Když je možné projekt upgradovat, je součástí řešení retargeting. Další informace naleznete v tématu IVsTrackProjectRetargeting2.
Pokud chcete přidat názvy projektů v Průzkumník řešení, když projekty používají konkrétní sadu nástrojů, definujte _PlatformToolsetShortNameFor_<safe_toolset_name>
vlastnost.
Příklady _UpgradePlatformToolsetFor_<safe_toolset_name>
definic vlastností naleznete _PlatformToolsetShortNameFor_<safe_toolset_name>
v souboru Microsoft.Cpp.Default.props . Příklady použití najdete v $(VCTargetPath)
\souboru Microsoft.Cpp.Platform.targets.
Upgrade vlastního projektu
Pokud chcete použít vlastní objekt upgradovače projektu, implementujte komponentu MEF, jak je znázorněno zde:
/// </summary>
[Export("MyProjectUpgrader", typeof(IProjectRetargetHandler))]
[Export(typeof(IProjectRetargetHandler))]
[ExportMetadata("Name", "MyProjectUpgrader")]
[OrderPrecedence(20)]
[PartMetadata(ProjectCapabilities.Requires, ProjectCapabilities.VisualC)]
internal class MyProjectUpgrader: IProjectRetargetHandler
{
// ...
}
Kód může importovat a volat výchozí objekt .vcxproj upgraderu:
// ...
[Import("VCDefaultProjectUpgrader")]
// ...
IProjectRetargetHandler Lazy<IProjectRetargetHandler>
VCDefaultProjectUpgrader { get; set; }
// ...
IProjectRetargetHandler
je definován v Microsoft.VisualStudio.ProjectSystem.VS.dll a je podobný IVsRetargetProjectAsync
.
VCProjectUpgraderObjectName
Definujte vlastnost, která systému projektu řekne, aby používal váš vlastní objekt upgraderu:
<PropertyGroup>
<VCProjectUpgraderObjectName>MyProjectUpgrader</VCProjectUpgraderObjectName>
</PropertyGroup>
Zakázání upgradu projektu
Pokud chcete zakázat upgrady projektů, použijte NoUpgrade
hodnotu:
<PropertyGroup>
<VCProjectUpgraderObjectName>NoUpgrade</VCProjectUpgraderObjectName>
</PropertyGroup>
Mezipaměť a rozšiřitelnost projektu
Pro zvýšení výkonu při práci s velkými řešeními C++ v sadě Visual Studio 2017 byla zavedena mezipaměť projektu. Implementuje se jako databáze SQLite naplněná daty projektu a pak se používá k načtení projektů bez načtení projektů MSBuild nebo CPS do paměti.
Vzhledem k tomu, že nejsou k dispozici žádné objekty CPS pro projekty .vcxproj načtené z mezipaměti, součásti MEF rozšíření, které importují UnconfiguredProject
nebo ConfiguredProject
nelze vytvořit. Pro podporu rozšiřitelnosti se mezipaměť projektu nepoužívá, když Visual Studio zjistí, jestli projekt používá (nebo je pravděpodobné, že používá) rozšíření MEF.
Tyto typy projektů jsou vždy plně načtené a mají objekty CPS v paměti, takže jsou pro ně vytvořená všechna rozšíření MEF:
Projekty po spuštění
Projekty, které mají vlastní upgrade projektu, to znamená, že definují
VCProjectUpgraderObjectName
vlastnostProjekty, které necílily desktopové windows, to znamená, že definují
ApplicationType
vlastnostProjekty sdílených položek (.vcxitems) a všechny projekty, které na ně odkazují importem projektů .vcxitems.
Pokud se žádná z těchto podmínek nezjistí, vytvoří se mezipaměť projektu. Mezipaměť obsahuje všechna data z projektu MSBuild, která jsou potřebná k zodpovězení get
dotazů na VCProjectEngine
rozhraních. To znamená, že všechny úpravy na úrovni bodů MSBuild a cílí na úrovni souboru provedené rozšířením by měly fungovat pouze v projektech načtených z mezipaměti.
Odeslání rozšíření
Informace o tom, jak vytvořit soubory VSIX, naleznete v tématu Doprava rozšíření sady Visual Studio. Informace o tom, jak přidat soubory do speciálních umístění instalace, například přidat soubory do části $(VCTargetsPath)
, viz Instalace mimo složku rozšíření.
Další materiály
Microsoft Build System (MSBuild) poskytuje modul sestavení a rozšiřitelný formát XML pro soubory projektu. Měli byste být obeznámeni se základními koncepty nástroje MSBuild a s tím, jak MSBuild pro Visual C++ funguje, abyste rozšířili systém projektů Visual C++ .
Rozhraní MEF (Managed Extensibility Framework) poskytuje rozhraní API rozšíření, která používají cps a systém projektů Visual C++. Přehled toho, jak CPS používá MEF, najdete v tématu CPS a MEF v přehledu meF VSProjectSystem.
Existující systém sestavení můžete přizpůsobit přidáním kroků sestavení nebo nových typů souborů. Další informace naleznete v tématu MSBuild (Visual C++) Přehled a Práce s vlastnostmi projektu.