You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Add a common ref project, reorganize projects in solution a bit.
* Add more junk to the common ref project file
* Moving netcoreapp files back into netcore ref project.
* Microsoft.Data namespace
* Microsoft.Data.Sql
* Microsoft.Data.SqlTypes
* Add netfx package references
* Batch 1 up to SqlCommand
* SqlCommand
* Up through SqlConnection
* Up through SqlDataAdapter
* Microsoft.Data.SqlClient
* Microsoft.Data.SqlClient.Diagnostic
* Microsoft.Data.SqlClient.Server
* MDS.Batch files and MDS.DataClassification
* Microsoft.Data.SqlClient.Manual ... whatever that means
* Fix mistakes in xml file paths, etc.
* Pointing separate ref projects at common files.
* Adding reference to abstractions to common ref project
* Comments from PR
* Add ref assembly comparison target.
* Clean up target.
* Rename to make it clear this is specific to MDS.
---------
Co-authored-by: Malcolm Daigle <mdaigle@microsoft.com>
Add a build target that compares locally-built ref assemblies against those published in a specified NuGet package version of Microsoft.Data.SqlClient. This detects any unintended API surface changes introduced during the ref project consolidation (PR #3963).
6
+
7
+
The comparison uses `Microsoft.DotNet.ApiCompat.Tool` in **strict mode**, which flags both additions and removals.
-`BaselinePackageVersion` is **required** (no default). The user must specify which published package to compare against.
16
+
- Both the **legacy** ref projects (`netcore/ref/`, `netfx/ref/`) and the **new consolidated** ref project (`ref/`) are built and compared independently, so you can distinguish whether a difference comes from source consolidation vs. project restructuring.
17
+
- All comparisons run to completion (errors don't short-circuit), so you see all differences at once.
18
+
19
+
## Implementation Steps
20
+
21
+
### 1. Register `Microsoft.DotNet.ApiCompat.Tool` in `dotnet-tools.json`
22
+
23
+
Add an entry for version `9.0.200` alongside the existing `dotnet-coverage` entry. This enables `dotnet apicompat` after `dotnet tool restore`.
A single new file containing all properties, items, and targets (steps 3–11 below). Follows the naming convention of existing files like `GenerateMdsPackage.targets`.
28
+
29
+
### 3. Define properties
30
+
31
+
| Property | Value | Notes |
32
+
|----------|-------|-------|
33
+
|`BaselinePackageVersion`|*(none)*| Required; validated by guard target |
34
+
|`BaselinePackageDir`|`$(Artifacts)apicompat\`| Working directory for downloads |
0 commit comments