Visual Studio C++ 프로젝트 시스템 확장성 및 도구 집합 통합
Visual C++ 프로젝트 시스템은 .vcxproj 파일에 사용됩니다. 이 기능은 CPS(공용 프로젝트 시스템) 기반으로 하며 새로운 도구 집합, 빌드 아키텍처 및 대상 플랫폼을 쉽게 통합할 수 있는 추가적인 C++ 특정 확장 지점을 제공합니다.
C++ MSBuild 대상 구조
모든 .vcxproj 파일은 다음 파일을 가져옵니다.
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.props" />
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" />
이러한 파일은 자체로는 거의 정의하지 않습니다. 대신 이러한 속성 값을 기반으로 다른 파일을 가져옵니다.
$(ApplicationType)
예: Windows 스토어, Android, Linux
$(ApplicationTypeRevision)
이 문자열은 major.minor[.build[.revision] 형식의 유효한 버전 문자열이어야 합니다.
예: 1.0, 10.0.0.0
$(Platform)
빌드 아키텍처는 기록상의 이유로 "플랫폼"으로 명명된 것입니다.
예: Win32, x86, x64, ARM
$(PlatformToolset)
예: v140, v141, v141_xp, llvm
이러한 속성 값은 $(VCTargetsPath)
루트 폴더 아래에 폴더 이름을 지정합니다.
$(VCTargetsPath)
\
애플리케이션 유형\
$(ApplicationType)
\
$(ApplicationTypeRevision)
\
플랫폼\
$(Platform)
\
PlatformToolsets\
$(PlatformToolset)
플랫폼\
$(Platform)
\
PlatformToolsets\
$(PlatformToolset)
$(VCTargetsPath)
\
Platforms\ 폴더는 Windows 데스크톱 프로젝트의 경우 $(ApplicationType)
비어 있을 때 사용됩니다.
새 플랫폼 도구 집합 추가
기존 Win32 플랫폼에 대한 "MyToolset"과 같은 새 도구 집합을 추가하려면 $(VCTargetsPath)
\Platforms\Win32\PlatformToolsets\아래에 MyToolset 폴더를 만들고 Toolset.props 및 Toolset.targets 파일을 만듭니다.
PlatformToolsets 아래의 각 폴더 이름은 다음과 같이 프로젝트 속성 대화 상자에 지정된 플랫폼에 대해 사용 가능한 플랫폼 도구 집합 표시됩니다.
유사한 MyToolset 폴더를 만들고, 이 도구 집합이 지원하는 각 기존 플랫폼 폴더에 Toolset.props 및 Toolset.targets 파일을 만듭니다.
새 플랫폼 추가
새 플랫폼(예: "MyPlatform")을 추가하려면 $(VCTargetsPath)
\Platforms\아래에 MyPlatform 폴더를 만들고 Platform.default.props, Platform.props및 Platform.targets 파일을 만듭니다. 또한 $(VCTargetsPath)
\Platforms\MyPlatform\PlatformToolsets\ 폴더를 만들고 하나 이상의 도구 집합을 만듭니다.
각 $(ApplicationType)
및 $(ApplicationTypeRevision)
Platforms 폴더 아래의 모든 폴더 이름은 프로젝트에 대해 사용 가능한 Platform 선택 항목으로 IDE에 표시됩니다.
새 애플리케이션 유형 추가
새 애플리케이션 유형을 추가하려면 $(VCTargetsPath)
\Application Type\MyApplicationType 폴더를 만들고 Defaults.props 파일을 만듭니다. 애플리케이션 유형에는 하나 이상의 수정 버전이 필요하므로 $(VCTargetsPath)
\Application Type\MyApplicationType\1.0 폴더를 만들고 Defaults.props 파일을 만듭니다. 또한 $(VCTargetsPath)
\ApplicationType\MyApplicationType\1.0\Platforms 폴더를 만들고 하나 이상의 플랫폼을 만들어야 합니다.
$(ApplicationType)
및 $(ApplicationTypeRevision)
속성은 사용자 인터페이스에 표시되지 않습니다. 프로젝트 템플릿에 정의되며 프로젝트를 만든 후에는 변경할 수 없습니다.
.vcxproj 가져오기 트리
Microsoft C++ props 및 targets 파일에 대한 간단한 가져오기 트리는 다음과 같습니다.
$(VCTargetsPath)
\ Microsoft.Cpp.Default.props
$(MSBuildExtensionsPath)
\$(MSBuildToolsVersion)
\ Microsoft.Common.props
ImportBefore\기본\*를$(VCTargetsPath)
\.소품
$(VCTargetsPath)
\ 애플리케이션 유형\$(ApplicationType)
\Default.props
$(VCTargetsPath)
\ 애플리케이션 유형\$(ApplicationType)
\$(ApplicationTypeRevision)
\Default.props
$(VCTargetsPath)
\ 애플리케이션 유형\$(ApplicationType)
\$(ApplicationTypeRevision)
\Platforms\$(Platform)
\Platform.default.props
$(VCTargetsPath)
\ ImportAfter\기본\*입니다.소품
Windows 데스크톱 프로젝트는 $(ApplicationType)
정의하지 않으므로 가져오기만 합니다.
$(VCTargetsPath)
\ Microsoft.Cpp.Default.props
$(MSBuildExtensionsPath)
\$(MSBuildToolsVersion)
\ Microsoft.Common.props
$(VCTargetsPath)
\ ImportBefore\기본값\*.소품
$(VCTargetsPath)
\ 플랫폼\$(Platform)
\Platform.default.props
$(VCTargetsPath)
\ ImportAfter\기본\*입니다.소품
$(_PlatformFolder)
속성을 사용하여 $(Platform)
플랫폼 폴더 위치를 보관합니다. 이 속성은
$(VCTargetsPath)
\ 플랫폼\$(Platform)
Windows 데스크톱 앱용 및
$(VCTargetsPath)
\ 애플리케이션 유형\$(ApplicationType)
\$(ApplicationTypeRevision)
\플랫폼\$(Platform)
그 외 모든 것에 대해
props 파일은 다음 순서로 가져옵니다.
$(VCTargetsPath)
\ microsoft.Cpp.props
$(_PlatformFolder)
\ Platform.props
$(VCTargetsPath)
\ microsoft.Cpp.Platform.props
$(_PlatformFolder)
\ ImportBefore\*.소품
$(_PlatformFolder)
\ PlatformToolsets\$(PlatformToolset)
\Toolset.props
$(_PlatformFolder)
\ ImportAfter\*.소품
대상 파일은 다음 순서로 가져옵니다.
$(VCTargetsPath)
\ Microsoft.Cpp.targets
$(VCTargetsPath)
\ Microsoft.Cpp.Current.targets
$(_PlatformFolder)
\ Platform.targets
$(VCTargetsPath)
\ Microsoft.Cpp.Platform.targets
$(_PlatformFolder)
\ ImportBefore\*.대상
$(_PlatformFolder)
\ PlatformToolsets\$(PlatformToolset)
\Toolset.target
importAfter\*$(_PlatformFolder)
\.대상
도구 집합에 대한 몇 가지 기본 속성을 정의해야 하는 경우 적절한 ImportBefore 및 ImportAfter 폴더에 파일을 추가할 수 있습니다.
Toolset.props 및 Toolset.targets 파일 작성
Toolset.props 및 Toolset.targets 파일은 이 도구 집합을 사용할 때 빌드 중에 발생하는 작업을 완전히 제어할 수 있습니다. 사용 가능한 디버거, 속성 페이지 대화 상자의 콘텐츠와 같은 일부 IDE 사용자 인터페이스 및 프로젝트 동작의 다른 측면을 제어할 수도 있습니다.
도구 집합은 전체 빌드 프로세스를 재정의할 수 있지만 일반적으로 도구 집합이 일부 빌드 단계를 수정하거나 추가하거나 기존 빌드 프로세스의 일부로 다른 빌드 도구를 사용하려고 합니다. 이 목표를 달성하기 위해 도구 집합에서 가져올 수 있는 일반적인 소품 및 대상 파일이 많이 있습니다. 도구 집합을 수행할 내용에 따라 이러한 파일은 가져오기 또는 예제로 사용하는 데 유용할 수 있습니다.
$(VCTargetsPath)
\ Microsoft.CppCommon.targets이 파일은 네이티브 빌드 프로세스의 주요 부분을 정의하고 다음을 가져옵니다.
$(VCTargetsPath)
\ Microsoft.CppBuild.targets$(VCTargetsPath)
\ Microsoft.BuildSteps.targets$(MSBuildToolsPath)
\ Microsoft.Common.Targets
$(VCTargetsPath)
\ Microsoft.Cpp.Common.propsMicrosoft 컴파일러 및 대상 Windows를 사용하는 도구 집합의 기본값을 설정합니다.
$(VCTargetsPath)
\ Microsoft.Cpp.WindowsSDK.props이 파일은 Windows SDK 위치를 결정하고 Windows를 대상으로 하는 앱에 대한 몇 가지 중요한 속성을 정의합니다.
도구 집합별 대상을 기본 C++ 빌드 프로세스와 통합
기본 C++ 빌드 프로세스는 Microsoft.CppCommon.targets 정의됩니다. 이 대상은 특정 빌드 도구를 호출하지 않습니다. 기본 빌드 단계, 순서 및 종속성을 지정합니다.
C++ 빌드에는 다음 대상으로 표시되는 세 가지 주요 단계가 있습니다.
BuildGenerateSources
BuildCompile
BuildLink
각 빌드 단계는 독립적으로 실행될 수 있으므로 한 단계에서 실행되는 대상은 다른 단계의 일부로 실행되는 대상에 정의된 항목 그룹 및 속성에 의존할 수 없습니다. 이 부서에서는 특정 빌드 성능 최적화를 허용합니다. 기본적으로 사용되지는 않지만 이 분리를 존중하는 것이 좋습니다.
각 단계 내에서 실행되는 대상은 다음 속성에 의해 제어됩니다.
$(BuildGenerateSourcesTargets)
$(BuildCompileTargets)
$(BeforeBuildLinkTargets)
각 단계에는 이전 및 이후 속성도 있습니다.
<Target
Name="_BuildGenerateSourcesAction"
DependsOnTargets="$(CommonBuildOnlyTargets);$(BeforeBuildGenerateSourcesTargets);$(BuildGenerateSourcesTargets);$(AfterBuildGenerateSourcesTargets)" />
<Target
Name="\_BuildCompileAction"
DependsOnTargets="$(CommonBuildOnlyTargets);$(BeforeBuildCompileTargets);$(BuildCompileTargets);$(AfterBuildCompileTargets)" />
<Target
Name="\_BuildLinkAction"
DependsOnTargets="$(CommonBuildOnlyTargets);$(BeforeBuildLinkTargets);$(BuildLinkTargets);$(AfterBuildLinkTargets)" />
각 단계에 포함된 대상의 예는 Microsoft.CppBuild.targets 파일을 참조하세요.
<BuildCompileTargets Condition="'$(ConfigurationType)'\!='Utility'">
$(BuildCompileTargets);
_ClCompile;
_ResGen;
_ResourceCompile;
$(BuildLibTargets);
</BuildCompileTargets>
_ClCompile
같은 대상을 보면 직접 아무 작업도 수행하지 않고 대신 ClCompile
포함한 다른 대상에 따라 달라지는 것을 볼 수 있습니다.
<Target Name="_ClCompile"
DependsOnTargets="$(BeforeClCompileTargets);$(ComputeCompileInputsTargets);MakeDirsForCl;ClCompile;$(AfterClCompileTargets)" >
</Target>
ClCompile
및 기타 빌드 도구별 대상은 Microsoft.CppBuild.targets 빈 대상으로 정의됩니다.
<Target Name="ClCompile"/>
ClCompile
대상은 비어 있으므로 도구 집합에서 재정의하지 않는 한 실제 빌드 작업이 수행되지 않습니다. 도구 집합 대상은 ClCompile
대상을 재정의할 수 있습니다. 즉, Microsoft.CppBuild.targets을(를) 가져온 후 다른 ClCompile
정의를 포함할 수 있습니다.
<Target Name="ClCompile"
Condition="'@(ClCompile)' != ''"
DependsOnTargets="SelectClCompile">
<!-- call some MSBuild tasks -->
</Target>
Visual Studio에서 플랫폼 간 지원을 구현하기 전에 만들어진 이름에도 불구하고 ClCompile
대상은 CL.exe호출할 필요가 없습니다. 적절한 MSBuild 작업을 사용하여 Clang, gcc 또는 기타 컴파일러를 호출할 수도 있습니다.
ClCompile
대상에는 단일 파일 컴파일 명령이 IDE에서 작동하는 데 필요한 SelectClCompile
대상을 제외한 종속성이 없어야 합니다.
도구 집합 대상에 사용할 MSBuild 작업
실제 빌드 도구를 호출하려면 대상이 MSBuild 작업을 호출해야 합니다. 실행할 명령줄을 지정할 수 있는 기본 Exec 작업 있습니다. 그러나 빌드 도구에는 일반적으로 증분 빌드를 추적할 수 있는 많은 옵션, 입력 및 출력이 있으므로 특별한 작업을 수행하는 것이 더 합리적입니다. 예를 들어 CL
작업은 MSBuild 속성을 CL.exe 스위치로 변환하고, 응답 파일에 쓰고, CL.exe호출합니다. 또한 이후 증분 빌드에 대한 모든 입력 및 출력 파일을 추적합니다. 자세한 내용은 증분 빌드 및 up-to-date 검사를 참조하세요.
Microsoft.Cpp.Common.Tasks.dll 다음 작업을 구현합니다.
BSCMake
CL
ClangCompile
(clang-gcc 스위치)LIB
LINK
MIDL
Mt
RC
XDCMake
CustomBuild
(예: Exec이지만 입력 및 출력 추적 사용)SetEnv
GetOutOfDateItems
기존 도구와 동일한 작업을 수행하고 명령줄 스위치가 비슷한 도구(clang-cl 및 CL처럼)가 있는 경우 둘 다에 대해 동일한 작업을 사용할 수 있습니다.
빌드 도구에 대한 새 작업을 만들어야 하는 경우 다음 옵션 중에서 선택할 수 있습니다.
이 작업을 거의 사용하지 않거나 빌드에 몇 초가 중요하지 않은 경우 MSBuild '인라인' 작업을 사용할 수 있습니다.
Xaml 작업(사용자 지정 빌드 규칙)
Xaml 작업 선언의 한 가지 예는
$(VCTargetsPath)
\BuildCustomizations\masm.xml참조하고 해당 사용은$(VCTargetsPath)
\BuildCustomizations\masm.targets참조하세요.
더 나은 작업 성능을 원하거나 더 복잡한 기능이 필요한 경우 일반 MSBuild 작업 쓰기 프로세스를 사용합니다.
도구의 모든 입력 및 출력이
CL
,MIDL
및RC
경우와 같이 도구 명령줄에 나열되지 않고 자동 입력 및 출력 파일 추적 및 .tlog 파일 생성을 원하는 경우Microsoft.Build.CPPTasks.TrackedVCToolTask
클래스에서 작업을 파생합니다. 현재 기본 ToolTask 클래스에 대한 설명서가 있지만TrackedVCToolTask
클래스의 세부 정보에 대한 예제나 설명서는 없습니다. 특히 관심이 있으시면 개발자 커뮤니티에 요청을 제안하거나 의견을 남겨주세요.
증분 빌드 및 up-to날짜 검사
기본 MSBuild 증분 빌드 대상은 Inputs
및 Outputs
특성을 사용합니다. 지정하는 경우 MSBuild는 입력에 모든 출력보다 최신 타임스탬프가 있는 경우에만 대상을 호출합니다. 원본 파일은 종종 다른 파일을 포함하거나 가져오며 빌드 도구는 도구 옵션에 따라 다른 출력을 생성하기 때문에 MSBuild 대상에서 가능한 모든 입력 및 출력을 지정하기가 어렵습니다.
이 문제를 관리하기 위해 C++ 빌드는 다른 기술을 사용하여 증분 빌드를 지원합니다. 대부분의 대상은 입력 및 출력을 지정하지 않으므로 빌드 중에 항상 실행됩니다. 대상에서 호출하는 작업은 모든 입력 및 출력에 대한 정보를 .tlog 확장명이 있는 로그 파일에 씁니다. .tlog 파일은 이후 빌드에서 변경된 내용과 다시 작성해야 하는 항목 및 up-to-date를 확인하는 데 사용됩니다. .tlog 파일은 IDE에서 기본 빌드 up-to-date check의 유일한 소스이기도 합니다.
모든 입력 및 출력을 확인하기 위해 네이티브 도구 작업은 MSBuild에서 제공하는 tracker.exe 및 FileTracker 클래스를 사용합니다.
Microsoft.Build.CPPTasks.Common.dll TrackedVCToolTask
공용 추상 기본 클래스를 정의합니다. 대부분의 네이티브 도구 작업은 이 클래스에서 파생됩니다.
Visual Studio 2017 업데이트 15.8부터 Microsoft.Cpp.Common.Tasks.dll 구현된 GetOutOfDateItems
작업을 사용하여 알려진 입력 및 출력이 있는 사용자 지정 대상에 대한 .tlog 파일을 생성할 수 있습니다.
또는 WriteLinesToFile
작업을 사용하여 만들 수 있습니다. 예를 들어, _WriteMasmTlogs
대상을 $(VCTargetsPath)
\BuildCustomizations\masm.targets에서 참조하세요.
.tlog 파일
.tlog 파일에는 세 가지 유형이 있습니다: 읽기, 쓰기, 그리고 명령줄. 읽기 및 쓰기 .tlog 파일은 증분 빌드 및 IDE의 up-to-date 검사에서 사용됩니다. 명령줄 .tlog 파일은 증분 빌드에서만 사용됩니다.
MSBuild는 .tlog 파일을 읽고 쓸 수 있는 다음과 같은 도우미 클래스를 제공합니다.
FlatTrackingData 클래스를 사용하여 읽기 및 쓰기 .tlog 파일에 모두 액세스하고 출력보다 최신인 입력을 식별하거나 출력이 누락된 경우 식별할 수 있습니다. up-to날짜 검증에 사용됩니다.
명령줄 .tlog 파일에는 빌드에 사용되는 명령줄에 대한 정보가 포함되어 있습니다. 그들은 up-to-date 검사가 아닌 증분 빌드에만 사용되므로, 내부 형식은 이를 생성하는 MSBuild 작업에 의해 결정됩니다.
.tlog 형식 읽기
읽기 .tlog 파일(*.read.*.tlog)에는 원본 파일 및 해당 종속성에 대한 정보가 포함되어 있습니다.
줄의 시작 부분에 있는 캐럿(^)은 하나 이상의 원본을 나타냅니다. 동일한 종속성을 공유하는 원본은 세로 막대(|)로 구분됩니다.
종속성 파일은 각각 자체 줄에 있는 원본 다음에 나열됩니다. 모든 파일 이름은 전체 경로입니다.
예를 들어 프로젝트 원본이 F:\test\ConsoleApplication1\ConsoleApplication1있다고 가정합니다. Class1.cpp원본 파일에 다음이 포함된 경우
#include "stdafx.h" //precompiled header
#include "Class1.h"
그런 다음 CL.read.1.tlog 파일에는 소스 파일과 두 종속성이 포함됩니다.
^F:\TEST\CONSOLEAPPLICATION1\CONSOLEAPPLICATION1\CLASS1.CPP
F:\TEST\CONSOLEAPPLICATION1\CONSOLEAPPLICATION1\DEBUG\CONSOLEAPPLICATION1.PCH
F:\TEST\CONSOLEAPPLICATION1\CONSOLEAPPLICATION1\CLASS1.H
대문자로 파일 이름을 작성할 필요는 없지만 일부 도구에서는 편리합니다.
.tlog 형식 작성
Write .tlog(*.write.*.tlog) 파일은 소스와 출력을 연결합니다.
줄의 시작 부분에 있는 캐럿(^)은 하나 이상의 원본을 나타냅니다. 여러 소스는 세로 막대(|)로 구분됩니다.
원본에서 빌드된 출력 파일은 각각 자체 줄에 있는 원본 뒤 나열되어야 합니다. 모든 파일 이름은 전체 경로여야 합니다.
예를 들어 추가 소스 파일 Class1.cpp있는 간단한 ConsoleApplication 프로젝트의 경우 link.write.1.tlog 파일에는 다음이 포함될 수 있습니다.
^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
디자인 시 빌드
IDE에서 .vcxproj 프로젝트는 MSBuild 대상 집합을 사용하여 프로젝트에서 추가 정보를 얻고 출력 파일을 다시 생성합니다. 이러한 대상 중 일부는 디자인 타임 빌드에서만 사용되지만, 그 중 상당수는 일반 빌드와 디자인 타임 빌드 모두에서 사용됩니다.
디자인 타임 빌드에 대한 일반적인 내용은 디자인 타임 빌드대한 CPS 설명서를 참조하세요. 이 설명서는 Visual C++ 프로젝트에만 부분적으로 적용됩니다.
디자인 타임 빌드 설명서에 언급된 CompileDesignTime
및 Compile
대상은 .vcxproj 프로젝트에 대해 실행되지 않습니다. Visual C++ .vcxproj 프로젝트는 다양한 디자인 타임 대상을 사용하여 IntelliSense 정보를 가져옵니다.
IntelliSense 정보에 대한 디자인 시간 대상
.vcxproj 프로젝트에 사용되는 디자인 타임 대상은 $(VCTargetsPath)
\Microsoft.Cpp.DesignTime.targets에서 정의됩니다.
GetClCommandLines
대상은 IntelliSense에 대한 컴파일러 옵션을 수집합니다.
<Target
Name="GetClCommandLines"
Returns="@(ClCommandLines)"
DependsOnTargets="$(DesignTimeBuildInitTargets);$(ComputeCompileInputsTargets)">
DesignTimeBuildInitTargets
– 디자인 타임 빌드 초기화에 필요한 디자인 타임 전용 대상입니다. 무엇보다도 이러한 대상은 성능을 향상시키기 위해 일부 일반 빌드 기능을 사용하지 않도록 설정합니다.ComputeCompileInputsTargets
– 컴파일러 옵션 및 항목을 수정하는 대상 집합입니다. 이러한 대상은 디자인 타임 및 일반 빌드 모두에서 실행됩니다.
대상은 CLCommandLine
작업을 호출하여 IntelliSense에 사용할 명령줄을 만듭니다. 이름에도 불구하고 CL 옵션뿐만 아니라 Clang 및 gcc 옵션도 처리할 수 있습니다. 컴파일러 스위치의 형식은 ClangMode
속성에 의해 제어됩니다.
현재 CLCommandLine
태스크에서 생성된 명령줄은 IntelliSense 엔진이 구문 분석하기 쉽기 때문에 CL 스위치(Clang 모드에서도)를 항상 사용합니다.
일반 또는 디자인 타임에 관계없이 컴파일 전에 실행되는 대상을 추가하는 경우 디자인 타임 빌드를 중단하거나 성능에 영향을 주지 않는지 확인합니다. 대상을 테스트하는 가장 간단한 방법은 개발자 명령 프롬프트를 열고 다음 명령을 실행하는 것입니다.
msbuild /p:SolutionDir=*solution-directory-with-trailing-backslash*;Configuration=Debug;Platform=Win32;BuildingInsideVisualStudio=true;DesignTimebuild=true /t:\_PerfIntellisenseInfo /v:d /fl /fileloggerparameters:PerformanceSummary \*.vcxproj
이 명령은 마지막에 대상 및 작업에 대한 성능 요약이 포함된 자세한 빌드 로그(msbuild.log)를 생성합니다.
디자인 타임 빌드가 아닌 일반 빌드에만 적합한 모든 작업에서 Condition ="'$(DesignTimeBuild)' != 'true'"
사용해야 합니다.
원본을 생성하는 디자인 타임 대상
이 기능은 데스크톱 네이티브 프로젝트에 대해 기본적으로 사용되지 않으며 현재 캐시된 프로젝트지원되지 않습니다.
프로젝트 항목에 대해 GeneratorTarget
메타데이터가 정의되면 프로젝트가 로드될 때와 원본 파일이 변경될 때 대상이 자동으로 실행됩니다.
예를 들어 .xaml 파일에서 .cpp 또는 .h 파일을 자동으로 생성하기 위해 $(VSInstallDir)
\MSBuild\Microsoft\WindowsXaml\v16.0\*\Microsoft.Windows.UI.Xaml.CPP.Targets 파일은 다음 엔터티를 정의합니다.
<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
사용하여 원본 파일의 저장되지 않은 콘텐츠를 얻으려면 대상과 태스크를 pkgdef의 지정된 프로젝트에 대한 MsbuildHostObjects 등록해야 합니다.
\[$RootKey$\\Projects\\{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}\\MSBuildHostObjects\]
\[$RootKey$\\Projects\\{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}\\MSBuildHostObjects\\DesignTimeMarkupCompilationCT;CompileXaml\]
@="{83046B3F-8984-444B-A5D2-8029DEE2DB70}"
Visual Studio IDE의 Visual C++ 프로젝트 확장성
Visual C++ 프로젝트 시스템은 VS Project System기반으로 하며 확장성 지점을 사용합니다. 그러나 프로젝트 계층 구조 구현은 CPS를 기반으로 하지 않고 Visual C++에만 적용되므로 계층 확장성은 프로젝트 항목으로 제한됩니다.
프로젝트 속성 페이지
일반적인 디자인 정보는 VC++ 프로젝트 대한Framework 다중 대상 지정을 참조하세요.
간단히 말하면 C++ 프로젝트의 프로젝트 속성 대화 상자에 표시되는 속성 페이지는 규칙 파일에 의해 정의됩니다. 규칙 파일은 속성 페이지에 표시할 속성 집합과 프로젝트 파일에 저장할 방법과 위치를 지정합니다. 규칙 파일은 Xaml 형식을 사용하는 .xml 파일입니다. Microsoft.Build.Framework.XamlTypes에서 직렬화하는 데 사용되는 형식이 설명되어 있습니다. 프로젝트에서 규칙 파일을 사용하는 방법에 대한 자세한 내용은 속성 페이지 XML 규칙 파일참조하세요.
규칙 파일을 PropertyPageSchema
항목 그룹에 추가해야 합니다.
<ItemGroup>
<PropertyPageSchema Include="$(VCTargetsPath)$(LangID)\general.xml;"/>
<PropertyPageSchema Include="$(VCTargetsPath)$(LangID)\general_file.xml">
<Context>File</Context>
</PropertyPageSchema>
</ItemGroup>
Context
메타데이터는 규칙 유형에 의해 제어되며 다음 값 중 하나를 가질 수 있는 규칙 표시 유형을 제한합니다.
Project
| File
| PropertySheet
CPS는 컨텍스트 형식에 대해 다른 값을 지원하지만 Visual C++ 프로젝트에서는 사용되지 않습니다.
규칙이 둘 이상의 컨텍스트에 표시되어야 하는 경우 다음과 같이 세미콜론(;)을 사용하여 컨텍스트 값을 구분합니다.
<PropertyPageSchema Include="$(MyFolder)\MyRule.xml">
<Context>Project;PropertySheet</Context>
</PropertyPageSchema>
규칙 형식 및 기본 형식
규칙 형식은 간단하므로 이 섹션에서는 사용자 인터페이스에서 규칙이 표시되는 방식에 영향을 주는 특성만 설명합니다.
<Rule
Name="ConfigurationGeneral"
DisplayName="General"
PageTemplate="generic"
Description="General"
xmlns="http://schemas.microsoft.com/build/2009/properties">
PageTemplate
특성은 속성 페이지 대화 상자에 규칙이 표시되는 방식을 정의합니다. 특성에는 다음 값 중 하나가 있을 수 있습니다.
속성 | 묘사 |
---|---|
generic |
모든 속성은 범주 제목 아래의 한 페이지에 표시됩니다. 규칙은 Project 및 PropertySheet 컨텍스트에서는 볼 수 있지만 File 컨텍스트에서는 볼 수 없습니다.예: $(VCTargetsPath) \1033\general.xml |
tool |
범주는 하위 페이지로 표시됩니다. 규칙은 Project , PropertySheet 및 File 모든 컨텍스트에서 볼 수 있습니다.프로젝트에 Rule.DataSource 에서 정의된 ItemType 를 포함하는 항목이 있는 경우에만, 규칙 이름이 ProjectTools 항목 그룹에 포함되지 않는 한 Project 속성에 규칙이 표시됩니다.예: $(VCTargetsPath) \1033\clang.xml |
debugger |
이 페이지는 디버깅 페이지의 일부로 표시됩니다. 범주는 현재 무시됩니다. 규칙 이름은 디버그 시작 관리자 MEF 개체의 ExportDebugger 특성과 일치해야 합니다.예: $(VCTargetsPath) \1033\debugger_local_windows.xml |
사용자 지정 | 사용자 지정 템플릿. 템플릿의 이름은 PropertyPageUIFactoryProvider MEF 개체의 ExportPropertyPageUIFactoryProvider 특성과 일치해야 합니다.
Microsoft.VisualStudio.ProjectSystem.Designers.Properties.IPropertyPageUIFactoryProvider참조하십시오.예: $(VCTargetsPath) \1033\userMacros.xml |
규칙이 Property Grid 기반 템플릿 중 하나를 사용하는 경우 해당 속성에 대해 다음 확장성 지점을 사용할 수 있습니다.
규칙을 확장하다
기존 규칙을 사용하지만 몇 가지 속성만 추가하거나 제거해야 하는 경우 확장 규칙만들 수 있습니다.
규칙 재정의
도구 집합에서 대부분의 프로젝트 기본 규칙을 사용하지만 그 중 하나 또는 몇 개만 바꾸려고 할 수 있습니다. 예를 들어 C/C++ 규칙을 변경하여 다른 컴파일러 스위치를 표시하려고 합니다. 기존 규칙과 동일한 이름과 표시 이름을 가진 새 규칙을 제공하고 기본 cpp 대상을 가져온 후 PropertyPageSchema
항목 그룹에 포함할 수 있습니다. 지정된 이름의 규칙 하나만 프로젝트에 사용되고 PropertyPageSchema
항목 그룹에 포함된 마지막 규칙이 우선합니다.
프로젝트 항목
ProjectItemsSchema.xml 파일은 프로젝트 항목으로 처리되는 항목에 대한 ContentType
및 ItemType
값을 정의하고 새 파일이 추가되는 항목 그룹을 결정하는 FileExtension
요소를 정의합니다.
기본 ProjectItemsSchema 파일은 $(VCTargetsPath)
\1033\ProjectItemsSchema.xml있습니다. 확장하려면 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>
그런 다음 대상 파일에서 다음을 추가합니다.
<ItemGroup>
<PropertyPageSchema Include="MyProjectItemsSchema.xml"/>
</ItemGroup>
예: $(VCTargetsPath)
\BuildCustomizations\masm.xml
디버거
Visual Studio의 디버그 서비스는 디버그 엔진에 대한 확장성을 지원합니다. 자세한 내용은 다음 샘플을 참조하세요.
MIEngine, lldb 디버깅 지원하는 오픈 소스 프로젝트
디버그 세션에 대한 디버그 엔진 및 기타 속성을 지정하려면 디버그 시작 관리자 MEF 구성 요소를 구현하고 debugger
규칙을 추가해야 합니다. 예제는 $(VCTargetsPath)
\1033\debugger_local_windows.xml 파일을 참조하세요.
전개시키다
.vcxproj 프로젝트는 Visual Studio 프로젝트 시스템 확장성을 사용하여 배포 공급자를지원합니다.
빌드 up-To- 날짜 확인
기본적으로 빌드 up-to-date 검사는 모든 빌드 입력 및 출력에 대해 빌드하는 동안 $(TlogLocation)
폴더에 .tlog 파일을 읽고 쓸 수 있도록 생성해야 합니다.
사용자 지정 up-to-date check를 사용하려면 다음을 수행합니다.
Toolset.targets 파일에
NoVCDefaultBuildUpToDateCheckProvider
기능을 추가하여 기본 up-to-date 검사를 사용하지 않도록 설정합니다.<ItemGroup> <ProjectCapability Include="NoVCDefaultBuildUpToDateCheckProvider" /> </ItemGroup>
고유한 IBuildUpToDateCheckProvider구현합니다.
프로젝트 업그레이드
기본 .vcxproj 프로젝트 업그레이드기
기본 .vcxproj 프로젝트 업그레이드는 PlatformToolset
, ApplicationTypeRevision
, MSBuild 도구 집합 버전 및 .NET Framework를 변경합니다. 마지막 두 가지는 항상 Visual Studio 버전 기본값으로 변경되지만 PlatformToolset
및 ApplicationTypeRevision
특수 MSBuild 속성으로 제어할 수 있습니다.
업그레이드 관리자는 다음 조건을 사용하여 프로젝트를 업그레이드할 수 있는지 여부를 결정합니다.
ApplicationType
정의하고ApplicationTypeRevision
프로젝트의 경우 현재 버전보다 수정 번호가 높은 폴더가 있습니다.속성
_UpgradePlatformToolsetFor_<safe_toolset_name>
현재 도구 집합에 대해 정의되며 해당 값은 현재 도구 집합과 같지 않습니다.이러한 속성 이름에서 <safe_toolset_name> 영숫자가 아닌 모든 문자가 밑줄(_)으로 대체된 도구 집합 이름을 나타냅니다.
업그레이드할 수 있는 경우, 프로젝트는 솔루션 대상 변경에 포함됩니다. 자세한 내용은 IVsTrackProjectRetargeting2를 참조하십시오.
프로젝트에서 특정 도구 집합을 사용할 때 솔루션 탐색기 프로젝트 이름을 표시하려면 _PlatformToolsetShortNameFor_<safe_toolset_name>
속성을 정의합니다.
_UpgradePlatformToolsetFor_<safe_toolset_name>
및 _PlatformToolsetShortNameFor_<safe_toolset_name>
속성 정의의 예는 Microsoft.Cpp.Default.props 파일을 참조하세요. 사용 예제는 $(VCTargetPath)
\Microsoft.Cpp.Platform.targets 파일을 참조하세요.
사용자 지정 프로젝트 업그레이드
사용자 지정 프로젝트 업그레이드자 개체를 사용하려면 다음과 같이 MEF 구성 요소를 구현합니다.
/// </summary>
[Export("MyProjectUpgrader", typeof(IProjectRetargetHandler))]
[Export(typeof(IProjectRetargetHandler))]
[ExportMetadata("Name", "MyProjectUpgrader")]
[OrderPrecedence(20)]
[PartMetadata(ProjectCapabilities.Requires, ProjectCapabilities.VisualC)]
internal class MyProjectUpgrader: IProjectRetargetHandler
{
// ...
}
코드는 기본 .vcxproj upgrader 개체를 가져오고 호출할 수 있습니다.
// ...
[Import("VCDefaultProjectUpgrader")]
// ...
IProjectRetargetHandler Lazy<IProjectRetargetHandler>
VCDefaultProjectUpgrader { get; set; }
// ...
IProjectRetargetHandler
Microsoft.VisualStudio.ProjectSystem.VS.dll 정의되며 IVsRetargetProjectAsync
비슷합니다.
VCProjectUpgraderObjectName
속성을 정의하여 프로젝트 시스템에 사용자 지정 업그레이드자 개체를 사용하도록 지시합니다.
<PropertyGroup>
<VCProjectUpgraderObjectName>MyProjectUpgrader</VCProjectUpgraderObjectName>
</PropertyGroup>
프로젝트 업그레이드 사용 안 함
프로젝트 업그레이드를 사용하지 않도록 설정하려면 NoUpgrade
값을 사용합니다.
<PropertyGroup>
<VCProjectUpgraderObjectName>NoUpgrade</VCProjectUpgraderObjectName>
</PropertyGroup>
프로젝트 캐시 및 확장성
Visual Studio 2017에서 대형 C++ 솔루션으로 작업할 때 성능을 향상시키기 위해 프로젝트 캐시 도입되었습니다. 프로젝트 데이터로 채워진 SQLite 데이터베이스로 구현된 다음 MSBuild 또는 CPS 프로젝트를 메모리에 로드하지 않고 프로젝트를 로드하는 데 사용됩니다.
캐시에서 로드된 .vcxproj 프로젝트에 대한 CPS 개체가 없으므로 UnconfiguredProject
또는 ConfiguredProject
가져오는 확장의 MEF 구성 요소를 만들 수 없습니다. 확장성을 지원하기 위해 Visual Studio에서 프로젝트에서 MEF 확장을 사용하는지(또는 사용할 가능성이 있는지) 감지할 때 프로젝트 캐시가 사용되지 않습니다.
이러한 프로젝트 형식은 항상 완전히 로드되어 메모리에 CPS 개체가 존재하므로, 모든 MEF 확장이 이에 대해 생성됩니다.
시작 프로젝트
사용자 지정 프로젝트 업그레이드기가 있는 프로젝트, 즉
VCProjectUpgraderObjectName
속성을 정의합니다.데스크톱 Windows를 대상으로 하지 않으며,
ApplicationType
속성을 정의하는 프로젝트들.공유 항목 프로젝트(.vcxitems) 및 .vcxitems 프로젝트를 가져와서 참조하는 모든 프로젝트입니다.
이러한 조건이 검색되지 않으면 프로젝트 캐시가 만들어집니다. 캐시에는 VCProjectEngine
인터페이스에서 get
쿼리에 응답하는 데 필요한 MSBuild 프로젝트의 모든 데이터가 포함됩니다. 즉, 확장 프로그램에서 수행하는 MSBuild props 및 targets 파일 수준의 모든 수정은 캐시에서 로드된 프로젝트에서만 작동합니다.
확장 프로그램 배포
VSIX 파일을 만드는 방법에 대한 정보를 보려면 Visual Studio 확장 도구을 참조하세요. 특수 설치 위치에 파일을 추가하는 방법(예: $(VCTargetsPath)
아래에 파일을 추가하는 방법)에 대한 자세한 내용은 확장 폴더 외부에 설치하는참조하세요.
추가 리소스
Microsoft Build System(MSBuild)은 프로젝트 파일에 대한 빌드 엔진 및 확장 가능한 XML 기반 형식을 제공합니다. Visual C++ 프로젝트 시스템을 확장하기 위해 기본 MSBuild 개념 및 visual C++ MSBuild가 작동하는 방식에 대해 잘 알고 있어야 합니다.
관리 확장성 프레임워크(MEF)는 CPS 및 Visual C++ 프로젝트 시스템에서 사용하는 확장 API를 제공합니다. CPS에서 MEF를 사용하는 방법에 대한 개요는 MEF VSProjectSystem 개요에서 CPS 및 MEF 참조하세요.
기존 빌드 시스템을 사용자 지정하여 빌드 단계 또는 새 파일 형식을 추가할 수 있습니다. 자세한 내용은 MSBuild(Visual C++) 개요 및 프로젝트 속성 작업을 참조하세요.