-
Notifications
You must be signed in to change notification settings - Fork 1.1k
/
Microsoft.NET.Sdk.CrossTargeting.targets
122 lines (101 loc) · 5.48 KB
/
Microsoft.NET.Sdk.CrossTargeting.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
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
<!--
***********************************************************************************************
Microsoft.NET.Sdk.targets
WARNING: DO NOT MODIFY this file unless you are knowledgeable about MSBuild and have
created a backup copy. Incorrect changes to this file will make it
impossible to load or build your projects from the command-line or the IDE.
Copyright (c) .NET Foundation. All rights reserved.
***********************************************************************************************
-->
<Project ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="Microsoft.NET.Sdk.Common.targets"/>
<Import Project="$(MSBuildThisFileDirectory)Microsoft.NET.Sdk.SourceLink.targets" Condition="'$(SuppressImplicitGitSourceLink)' != 'true'"/>
<!--
============================================================
Publish
This is the Publish target for cross-targeting.
Currently it is unsupported to publish for multiple target frameworks
because users can specify the $(PublishDir), and publish would put
multiple published applications in a single directory.
============================================================
-->
<Target Name="Publish" Condition=" '$(IsPublishable)' != 'false' ">
<ItemGroup>
<_PublishTargetFrameworks Include="$(TargetFrameworks)" />
</ItemGroup>
<NETSdkError ResourceName="PublishUnsupportedWithoutTargetFramework"
FormatArguments="@(_PublishTargetFrameworks, ', ')" />
</Target>
<!--
============================================================
GetAllRuntimeIdentifiers
Outer build implementation of GetAllRuntimeIdentifiers returns
a union of all runtime identifiers used across inner and outer
build evaluations.
It is further set to run before '_GenerateRestoreProjectSpec'
(note that running only 'Restore' is too late and will not work
with solution level restore). This ensures that any conditioning
of runtime identifiers against TargetFramework does not prevent
restore from providing the necessary RID-specific assets for all
inner builds.
It also brings parity to VS vs. command line behavior in this
scenario because VS passes all of the information from each
configured inner build to restore, whereas command-line restore
without this target would only use the runtime identifiers that
are statically set in the outer evaluation.
============================================================
-->
<Target Name="GetAllRuntimeIdentifiers"
Returns="$(RuntimeIdentifiers)"
BeforeTargets="_GenerateRestoreProjectSpec">
<ItemGroup>
<_GetAllRuntimeIdentifiersTargetFrameworks Include="$(TargetFrameworks)" />
<_AllRuntimeIdentifiers Include="$(RuntimeIdentifiers);$(RuntimeIdentifier)" />
</ItemGroup>
<MSBuild Projects="$(MSBuildProjectFile)"
Targets="GetAllRuntimeIdentifiers"
Properties="TargetFramework=%(_GetAllRuntimeIdentifiersTargetFrameworks.Identity)">
<Output ItemName="_AllRuntimeIdentifiers" TaskParameter="TargetOutputs" />
</MSBuild>
<PropertyGroup>
<RuntimeIdentifiers>@(_AllRuntimeIdentifiers->Distinct())</RuntimeIdentifiers>
</PropertyGroup>
</Target>
<!--
============================================================
GetPackagingOutputs
Stub cross-targeting implementation of GetPackagingOutputs
to allow project references from from projects that pull in
Microsoft.AppxPackage.targets (UWP, PCL) to cross-targeted
projects.
Ultimately, the appx targets should be modified to use the
same P2P TFM negotiation protocol as Microsoft.Common.targets
so that they can forward to the TFM-specific GetPackagingOutputs
of the appropriate inner build. This stub would not have any
bad interaction with that change, which would happily bypass
this implementation altogether.
An empty GetPackagingOutputs is sufficient for the common
case of a library with no special assets to contribute to
the appx and is also equivalent to what is present in the
single-targeted case unless WindowsAppContainer is not set
to true.
Furthermore, the appx targets currently use continue-on-error
such that even without this, clean builds succeed but log an
error and incremental builds silently succeed. As such, this
simply removes a confounding error from successful clean
builds.
============================================================
-->
<Target Name="GetPackagingOutputs" />
<!-- This exists as a workaround for https://github.com/Microsoft/msbuild/issues/3558 -->
<PropertyGroup Condition="'$(DefaultProjectTypeGuid)' == ''">
<DefaultProjectTypeGuid Condition="'$(MSBuildProjectExtension)' == '.csproj'">{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</DefaultProjectTypeGuid>
<DefaultProjectTypeGuid Condition="'$(MSBuildProjectExtension)' == '.vbproj'">{F184B08F-C81C-45F6-A57F-5ABD9991F28F}</DefaultProjectTypeGuid>
<!-- Note: F# sets DefaultProjectTypeGuid in the F# SDK -->
</PropertyGroup>
<!-- Default to the portable RID graph in the outer build as APICompat relies on it. -->
<PropertyGroup Condition="'$(RuntimeIdentifierGraphPath)' == ''">
<!-- The portable RID graph should be in the same directory as the full RID graph -->
<RuntimeIdentifierGraphPath>$([System.IO.Path]::GetDirectoryName($(BundledRuntimeIdentifierGraphFile)))/PortableRuntimeIdentifierGraph.json</RuntimeIdentifierGraphPath>
</PropertyGroup>
</Project>