-
Notifications
You must be signed in to change notification settings - Fork 11
Expand file tree
/
Copy pathDirectory.Packages.props
More file actions
193 lines (177 loc) · 12.3 KB
/
Copy pathDirectory.Packages.props
File metadata and controls
193 lines (177 loc) · 12.3 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
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
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
<Project>
<!--
Central Package Management (CPM). ManagePackageVersionsCentrally makes every
<PackageReference> across the solution version-less; the single source of truth for each
package's version is the matching <PackageVersion> below. This prevents the per-csproj
version drift the old layout invited (e.g. WireMock.Net 1.7.5 vs 1.8.0, or
Microsoft.Extensions.* split across 10.0.0 / 10.0.5).
Security-motivated version pins keep their rationale HERE, next to the version, so the
"why is this floor forced" note travels with the number instead of being scattered across
project files. Package-asset metadata (IncludeAssets / PrivateAssets) stays on the
PackageReference in each csproj — only the Version attribute moved out.
-->
<PropertyGroup>
<ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
<!-- The test-tooling PackageVersions below keep their floating "latest-in-band" pins
(17.* / 2.* / 4.* / 8.* / 6.*) — same intent the per-csproj refs carried before CPM.
NU1011 forbids floating central versions unless this opt-in is set. -->
<CentralPackageFloatingVersionsEnabled>true</CentralPackageFloatingVersionsEnabled>
</PropertyGroup>
<!-- ASP.NET Core / hosting / auth -->
<ItemGroup>
<PackageVersion Include="Microsoft.AspNetCore.Authentication.JwtBearer" Version="10.0.12" />
<PackageVersion Include="Microsoft.AspNetCore.Authentication.Negotiate" Version="10.0.12" />
<PackageVersion Include="Microsoft.AspNetCore.Authentication.OpenIdConnect" Version="10.0.12" />
<PackageVersion Include="Microsoft.AspNetCore.SignalR.Client" Version="10.0.12" />
<PackageVersion Include="Microsoft.Extensions.Hosting" Version="10.0.12" />
<PackageVersion Include="Microsoft.Extensions.Hosting.WindowsServices" Version="10.0.12" />
<PackageVersion Include="Microsoft.Extensions.Diagnostics.HealthChecks.EntityFrameworkCore" Version="10.0.12" />
<PackageVersion Include="System.DirectoryServices.Protocols" Version="10.0.12" />
<PackageVersion Include="System.Diagnostics.EventLog" Version="10.0.10" />
<PackageVersion Include="BCrypt.Net-Next" Version="4.2.0" />
</ItemGroup>
<!-- Microsoft.Extensions.* (unified to 10.0.10 — the whole 10.0.x surface moves as one band) -->
<ItemGroup>
<!-- Keep every Microsoft.Extensions.* entry on the SAME servicing patch: Http 10.0.10
transitively floors DependencyInjection at >= 10.0.10, and a mixed set trips NU1605. -->
<PackageVersion Include="Microsoft.Extensions.DependencyInjection" Version="10.0.12" />
<PackageVersion Include="Microsoft.Extensions.Http" Version="10.0.12" />
<PackageVersion Include="Microsoft.Extensions.Logging.Abstractions" Version="10.0.12" />
<PackageVersion Include="Microsoft.Extensions.Options.ConfigurationExtensions" Version="10.0.12" />
<PackageVersion Include="Microsoft.Extensions.Configuration" Version="10.0.12" />
<PackageVersion Include="Microsoft.Extensions.Configuration.Abstractions" Version="10.0.12" />
<!-- GetValue<T>() lives in the Binder package; WinRmSessionPool needs it to compile. -->
<PackageVersion Include="Microsoft.Extensions.Configuration.Binder" Version="10.0.12" />
<PackageVersion Include="Microsoft.Extensions.Configuration.Json" Version="10.0.12" />
<PackageVersion Include="Microsoft.Extensions.Configuration.CommandLine" Version="10.0.12" />
<PackageVersion Include="Microsoft.Extensions.Configuration.EnvironmentVariables" Version="10.0.12" />
</ItemGroup>
<!-- Entity Framework Core / database drivers -->
<ItemGroup>
<PackageVersion Include="Microsoft.EntityFrameworkCore.Design" Version="10.0.12" />
<PackageVersion Include="Microsoft.EntityFrameworkCore.Sqlite" Version="10.0.12" />
<PackageVersion Include="Microsoft.EntityFrameworkCore.SqlServer" Version="10.0.12" />
<PackageVersion Include="Npgsql.EntityFrameworkCore.PostgreSQL" Version="10.0.3" />
<PackageVersion Include="Npgsql" Version="10.0.3" />
<PackageVersion Include="Microsoft.Data.SqlClient" Version="7.1.0" />
<PackageVersion Include="Microsoft.Data.Sqlite" Version="10.0.12" />
<!-- Direct pin: Microsoft.Data.Sqlite 10.x still floors SQLitePCLRaw at 2.1.11, whose
lib.e_sqlite3 bundles SQLite < 3.50.2 (GHSA-2m69-gcr7-jv3q / CVE-2025-6965, HIGH).
The 3.x line ships SQLite 3.50.4+ (via SourceGear.sqlite3) and closes the CVE —
referenced directly by every project that references a *Sqlite package so the
transitive graph resolves to the fixed native build. -->
<PackageVersion Include="SQLitePCLRaw.bundle_e_sqlite3" Version="3.0.5" />
</ItemGroup>
<!-- Remote execution / scheduling -->
<ItemGroup>
<!-- SDK and System.Management.Automation are one release train — never split them. -->
<PackageVersion Include="Microsoft.PowerShell.SDK" Version="7.6.6" />
<PackageVersion Include="System.Management.Automation" Version="7.6.6" />
<!-- Quartz + Quartz.Extensions.Hosting pinned to the same version so the Cron evaluator
(Data, maintenance windows) and the scheduler host (Scheduler) never drift. -->
<PackageVersion Include="Quartz" Version="4.2.1" />
<PackageVersion Include="Quartz.Extensions.Hosting" Version="4.2.1" />
</ItemGroup>
<!-- Serilog logging -->
<ItemGroup>
<PackageVersion Include="Serilog" Version="4.4.0" />
<!-- AspNetCore / Extensions.Hosting / Settings.Configuration are one family and were split
across 9.x / 10.0.0 until now; they move together so the host builder extension methods
and the configuration reader agree on the same Serilog.Extensions.* surface. -->
<PackageVersion Include="Serilog.AspNetCore" Version="10.0.0" />
<PackageVersion Include="Serilog.Extensions.Hosting" Version="10.0.0" />
<PackageVersion Include="Serilog.Settings.Configuration" Version="10.0.1" />
<PackageVersion Include="Serilog.Formatting.Compact" Version="3.0.0" />
<PackageVersion Include="Serilog.Sinks.Async" Version="2.1.0" />
<PackageVersion Include="Serilog.Sinks.Console" Version="6.1.1" />
<PackageVersion Include="Serilog.Sinks.File" Version="7.0.0" />
<PackageVersion Include="Serilog.Sinks.OpenTelemetry" Version="4.2.0" />
</ItemGroup>
<!--
OpenTelemetry — the whole stack tracks one release, currently 1.19. Core packages and the
contrib instrumentation packages ship patch versions independently, so the release is the
major.minor pair. OpenTelemetryVersionParityTests enforces this. The earlier jump to
1.15.3 was security-motivated (GHSA-8785-wc3w-h8q6 / GHSA-g94r-2vxg-569j on Api,
GHSA-mr8r-92fq-pj8p on OtlpExporter, plus a newer System.Security.Cryptography.Xml that
cleared GHSA-37gx-xxp4-5rgx / GHSA-w3x6-4m5h-cxqf); 1.17.0 keeps all of those closed and
pulls the instrumentation packages, which had lagged at 1.12.0, back onto the same number.
The three prerelease packages still have NO stable 1.x — the maintainer keeps Prometheus /
Process / EntityFrameworkCore instrumentation off the stable channel even at 1.17. Pinned to
the matching prerelease of the same release; note Process moved beta → rc for 1.17. The EF
tracer's SetDbStatementForText is FALSE (OpenTelemetryExtensions.cs) so SQL command text
never lands in a span — only operation type / db.system / db.name.
Dependabot's minor/patch group moves only the stable packages. Move the three prereleases
with them: the Prometheus exporter binds to internals of its own core release and fails every
scrape against another one, so its version must match OpenTelemetry exactly (up to the
prerelease suffix).
-->
<ItemGroup>
<PackageVersion Include="OpenTelemetry" Version="1.19.1" />
<PackageVersion Include="OpenTelemetry.Extensions.Hosting" Version="1.19.1" />
<PackageVersion Include="OpenTelemetry.Exporter.OpenTelemetryProtocol" Version="1.19.1" />
<PackageVersion Include="OpenTelemetry.Instrumentation.AspNetCore" Version="1.19.0" />
<PackageVersion Include="OpenTelemetry.Instrumentation.Http" Version="1.19.0" />
<PackageVersion Include="OpenTelemetry.Instrumentation.Runtime" Version="1.19.0" />
<PackageVersion Include="OpenTelemetry.Exporter.Prometheus.AspNetCore" Version="1.19.1-beta.1" />
<PackageVersion Include="OpenTelemetry.Instrumentation.Process" Version="1.19.0-rc.1" />
<PackageVersion Include="OpenTelemetry.Instrumentation.EntityFrameworkCore" Version="1.19.1-beta.1" />
</ItemGroup>
<!-- OpenAPI / API tooling -->
<ItemGroup>
<PackageVersion Include="Swashbuckle.AspNetCore" Version="10.2.3" />
<!-- Pin Microsoft.OpenApi above Swashbuckle 10.2.3's transitive 2.7.5
(GHSA-v5pm-xwqc-g5wc, HIGH, uncontrolled-recursion DoS via circular schema refs).
2.9.0 is still 2.x so Swashbuckle's Models namespace stays compatible — do NOT take
Microsoft.OpenApi 3.x while Swashbuckle 10.x asks for the 2.x surface.
Also forced in Api.Tests over WireMock.Net.OpenApiParser's 2.4.1. -->
<PackageVersion Include="Microsoft.OpenApi" Version="2.12.2" />
</ItemGroup>
<!-- Security-pinned floors over vulnerable transitives -->
<ItemGroup>
<!-- System.Security.Cryptography.Xml (transitive via Microsoft.PowerShell.SDK) brings a
version vulnerable to a chain of advisories; the 2026-07-21 patch batch
(GHSA-cvvh-rhrc-wg4q / -g8r8-53c2-pm3f / -23rf-6693-g89p / -8q5v-6pqq-x66h) is only
cleared in 10.0.10. Force it. -->
<PackageVersion Include="System.Security.Cryptography.Xml" Version="10.0.10" />
<PackageVersion Include="System.Security.Cryptography.ProtectedData" Version="10.0.12" />
</ItemGroup>
<!-- CLI / MCP / misc -->
<ItemGroup>
<!-- Spectre held at 0.55.0 as a family, NOT at Spectre.Console's newer 0.57.2: the CLI
package's stable line stops at 0.55.0 (everything after is a 1.0.0-alpha prerelease)
and it pins Spectre.Console to its own version. Splitting the two would pair a 0.57
core with a CLI built against 0.55 — on a 0.x library that is a real risk, so the
whole family moves together and waits for Spectre.Console.Cli 1.0. -->
<PackageVersion Include="Spectre.Console" Version="0.55.0" />
<PackageVersion Include="Spectre.Console.Cli" Version="0.55.0" />
<PackageVersion Include="Spectre.Console.Json" Version="0.55.0" />
<PackageVersion Include="Spectre.Console.Testing" Version="0.55.0" />
<!-- CommandAppTester left Spectre.Console.Testing when the CLI split into its own
package; the test harness needs this alongside the plain console test helpers. -->
<PackageVersion Include="Spectre.Console.Cli.Testing" Version="0.55.0" />
<PackageVersion Include="ModelContextProtocol" Version="2.2.0" />
<PackageVersion Include="Newtonsoft.Json" Version="13.0.4" />
</ItemGroup>
<!-- Test tooling (floating minors are intentional "latest-in-band" pins) -->
<ItemGroup>
<PackageVersion Include="Microsoft.NET.Test.Sdk" Version="18.*" />
<!-- xunit.v3, not the `xunit` package: the 2.x line ended at 2.9.3 and NuGet marks it
deprecated (Legacy) with xunit.v3 as the successor. v3 ships under a NEW package id,
so no version bump can ever reach it. v3 test projects must be executables — the
package's own targets hard-error otherwise — and it generates the entry point itself.
xunit.runner.visualstudio stays on the matching major so `dotnet test` keeps running
through VSTest, which is what the coverage collector in CI hooks into. -->
<PackageVersion Include="xunit.v3" Version="3.*" />
<PackageVersion Include="xunit.runner.visualstudio" Version="3.*" />
<PackageVersion Include="coverlet.collector" Version="10.*" />
<PackageVersion Include="Moq" Version="4.*" />
<PackageVersion Include="FluentAssertions" Version="8.*" />
<PackageVersion Include="Microsoft.AspNetCore.Mvc.Testing" Version="10.0.12" />
<!-- 2.x asks for Scriban.Signed 7.2.5 itself, so the forced floor that used to sit here
for GHSA-24c8-4792-22hx is gone — keeping it would only cap a future Scriban bump
that WireMock wants. The Microsoft.OpenApi floor above is still load-bearing. -->
<PackageVersion Include="WireMock.Net" Version="2.15.0" />
<PackageVersion Include="NBomber" Version="6.*" />
<PackageVersion Include="NBomber.Http" Version="6.*" />
</ItemGroup>
</Project>