Repository navigation
Expand file tree
/
Copy pathDirectory.Build.props
More file actions
90 lines (78 loc) · 5.13 KB
/
Copy pathDirectory.Build.props
File metadata and controls
90 lines (78 loc) · 5.13 KB
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
<Project>
<PropertyGroup>
<Version>5.4.1</Version>
<Authors>CaffeinatedCoder</Authors>
<PackageLicenseExpression>MIT</PackageLicenseExpression>
<GenerateDocumentationFile>true</GenerateDocumentationFile>
<TreatWarningsAsErrors>true</TreatWarningsAsErrors>
<PackageProjectUrl>https://github.com/CaffeinatedCoder/EFCore.ComplexIndexes</PackageProjectUrl>
<RepositoryUrl>https://github.com/CaffeinatedCoder/EFCore.ComplexIndexes</RepositoryUrl>
<RepositoryType>git</RepositoryType>
</PropertyGroup>
<!--
Warnings are errors, with one carve-out.
GenerateDocumentationFile means CS1591 (missing XML comment) polices the public surface: the
.xml shipped in the package is what a consumer sees in IntelliSense, and a hole in it is a
hole in the API documentation. Making it an error is the only thing that keeps that true —
64 of them had accumulated by 5.0.2.
NU1903 stays a warning. It reports a vulnerable *transitive* package, so whether the build
passes depends on advisories published upstream rather than on anything in this commit; as an
error it would break unrelated CI runs at unpredictable moments. It must stay visible, so it
is exempted rather than suppressed with NoWarn.
As of 5.0.2 it fires for System.Security.Cryptography.Xml 9.0.0, reached only through
Microsoft.EntityFrameworkCore.Design -> Microsoft.Build.Tasks.Core. That reference is
PrivateAssets=all, so the package never declares it and consumers never restore it: the
exposure is limited to machines building this repository. Bumping Design to 10.0.11 clears
the warning but drags the direct Abstractions reference up with it (NU1605 rejects the
downgrade), which would raise the consumer's EF Core floor from 10.0.0 to 10.0.11. Keeping
the floor low is worth more than silencing a warning that describes no consumer risk.
-->
<PropertyGroup>
<WarningsNotAsErrors>NU1901;NU1902;NU1903;NU1904</WarningsNotAsErrors>
</PropertyGroup>
<!--
GeneratePackageOnBuild is deliberately NOT set. The SDK's pack targets prepend `Build` to
GenerateNuspecDependsOn only when NoBuild != true AND GeneratePackageOnBuild != true, so
turning it on silently makes plain `dotnet pack` behave as if the no-build switch had been
passed. That packs whatever happens to be in bin/ — stale output on a laptop, and NU5026 on
a clean checkout where bin/ is empty, which is how CI found it.
-->
<!--
Every pack is checked against the last release for API breaks.
At pack time the SDK restores each package at the baseline version from nuget.org and runs
ApiCompat over the public surface — a removed or changed member fails the pack
(CP0001/CP0002/...), in CI's Pack job and in the release gate. Until now a removed public
member packed cleanly, and whether a release broke anyone rested on reading the diff.
The baseline is the last release. When Version is bumped for the next one it stays as the
release being superseded, and PackagingConventionTests requires it to be that release or the
shipped version — never older — so it moves with every bump instead of fossilising. For a
release that breaks on purpose: run
`dotnet pack -c Release /p:ApiCompatGenerateSuppressionFile=true`, read the generated
CompatibilitySuppressions.xml — each entry is one breaking change and belongs in the
changelog — commit it, and delete it after the release once the baseline moves past it. A
new package with no release yet sets PackageValidationBaselineVersion empty in its own
csproj until it has one.
-->
<PropertyGroup>
<EnablePackageValidation>true</EnablePackageValidation>
<PackageValidationBaselineVersion>5.4.0</PackageValidationBaselineVersion>
</PropertyGroup>
<!--
Debugging support for consumers.
Symbols ship as a separate .snupkg, which `dotnet nuget push` uploads alongside the .nupkg
automatically unless the no-symbols switch is passed, so the workflow needs no extra step.
Source Link is built into the .NET 8+ SDK — no package reference needed. PublishRepositoryUrl
stamps the repository and commit into the package so a debugger can fetch the exact sources;
EmbedUntrackedSources covers generated files that are not in git.
ContinuousIntegrationBuild is deliberately CI-only. It normalizes source paths for
reproducible builds, which is what you want in a published package but not on a laptop, where
it would break local step-into debugging of your own working copy. GitHub Actions sets CI=true.
-->
<PropertyGroup>
<IncludeSymbols>true</IncludeSymbols>
<SymbolPackageFormat>snupkg</SymbolPackageFormat>
<PublishRepositoryUrl>true</PublishRepositoryUrl>
<EmbedUntrackedSources>true</EmbedUntrackedSources>
<ContinuousIntegrationBuild Condition="'$(CI)' == 'true'">true</ContinuousIntegrationBuild>
</PropertyGroup>
</Project>