generated from jingkecn/MyScript.InteractiveInk.Starter.UWP
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Directory.Build.targets
61 lines (61 loc) · 3.48 KB
/
Directory.Build.targets
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
<!--
~ INTRO:
~ Directory.Build.targets is imported from Microsoft.Common.targets after importing .targets files from NuGet
~ packages. So, it can override properties and targets defined in most of the build logic, but sometimes you may need
~ to customize the project file after the final import.
~ General GUIDELINES:
~ - For many properties, it doesn't matter where they're defined, because they're not overwritten and will be read
~ only at execution time.
~ - For behavior that might be customized in an individual project, set defaults in .props files.
~ - Avoid setting dependent properties in .props files by reading the value of a possibly customized property,
~ because the customization won't happen until MSBuild reads the user's project.
~ - Set dependent properties in .targets files, because they'll pick up customizations from individual projects.
~ - If you need to override properties, do it in a .targets file, after all user-project customizations have had a
~ chance to take effect. Be cautious when using derived properties; derived properties may need to be overridden
~ as well.
~ - Include items in .props files (conditioned on a property). All properties are considered before any item, so
~ user-project property customizations get picked up, and this gives the user's project the opportunity to Remove
~ or Update any item brought in by the import.
~ - Define targets in .targets files. However, if the .targets file is imported by an SDK, remember that this
~ scenario makes overriding the target more difficult because the user's project doesn't have a place to override
~ it by default.
~ - If possible, prefer customizing properties at evaluation time over changing properties inside a target. This
~ guideline makes it easier to load a project and understand what it's doing.
-->
<!-- See: https://docs.microsoft.com/en-us/visualstudio/msbuild/customize-your-build?view=vs-2017#import-order -->
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<!-- Common -->
<PropertyGroup>
<RootNamespace>$(Company).$(Product).$(ProjectName)</RootNamespace>
</PropertyGroup>
<!-- Build -->
<PropertyGroup>
<ErrorReport>prompt</ErrorReport>
<!--
~ Workaround for NuGet issue.
~ See: https://github.com/NuGet/Home/wiki/%5BSpec%5D-Transitive-Warning-Properties
-->
<NoWarn>NU1603;$(NoWarn)</NoWarn>
<Prefer32Bit>false</Prefer32Bit>
<!-- <UseDotNetNativeToolchain>true</UseDotNetNativeToolchain> -->
<UseVSHostingProcess>false</UseVSHostingProcess>
</PropertyGroup>
<!-- Build (Debug) -->
<PropertyGroup Condition="'$(Configuration)' == 'Debug'">
<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
<DefineConstants>DEBUG;$(DefineConstants)</DefineConstants>
<!-- Enable .NET Native 2.0 Incremental Build Support
~ See: https://github.com/microsoft/dotnet/blob/master/releases/UWP/net-native2.0/incremental-compilation.md
-->
<!-- <UseDotNetNativeIncremental>true</UseDotNetNativeIncremental> -->
</PropertyGroup>
<!-- Build (Release) -->
<PropertyGroup Condition="'$(Configuration)' == 'Release'">
<DebugType>pdbonly</DebugType>
<Optimize>true</Optimize>
<UseDotNetNativeToolchain>true</UseDotNetNativeToolchain>
</PropertyGroup>
<!-- Import shared properties for all projects. -->
<Import Project="$(RootDir)/shared/Properties/Properties.projitems" Label="Shared" />
</Project>