Sdílet prostřednictvím


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:

Vlastnost Sada nástrojů platformy v dialogovém okně Stránky vlastností projektu

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.

Volba Nová platforma v dialogovém okně Nová platforma projektu

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.targets

    Tento 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.props

    Nastaví výchozí hodnoty sad nástrojů, které používají kompilátory Microsoftu a cílová okna.

  • $(VCTargetsPath)\Microsoft.Cpp.WindowsSDK.props

    Tento 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í:

  1. 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.

    • Úkol kódu

  2. 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, MIDLa RC případy, a pokud chcete automatické sledování vstupních a výstupních souborů a vytvoření souboru .tlog, odvozte úlohu z Microsoft.Build.CPPTasks.TrackedVCToolTask třídy. V současné době existuje dokumentace pro základní třídu ToolTask , neexistují žádné příklady ani dokumentace pro podrobnosti TrackedVCToolTask 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: ProjectPropertySheet 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:

  1. Zakažte výchozí aktuální kontrolu přidáním NoVCDefaultBuildUpToDateCheckProvider funkce do souboru Toolset.targets :

    <ItemGroup>
      <ProjectCapability Include="NoVCDefaultBuildUpToDateCheckProvider" />
    </ItemGroup>
    
  2. Implementujte vlastní IBuildUpToDateCheckProvider.

Upgrade projektu

Výchozí upgrade projektu .vcxproj

Výchozí .vcxproj upgrade projektu změní PlatformToolsetverzi sady nástrojů MSBuild ApplicationTypeRevisiona 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:

  1. Pro projekty, které definují ApplicationType a ApplicationTypeRevision, existuje složka s vyšším číslem revize než aktuální.

  2. 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 vlastnost

  • Projekty, které necílily desktopové windows, to znamená, že definují ApplicationType vlastnost

  • Projekty 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.