Referencing an old version of the sourcelink packages will make them win over whatever is inserted into the .NET SDK. The overall ability to reference sourcelink packages out-of-band is good but it shouldn't replace newer implementations that are part of the SDK.
The impact: Customers continue to reference sourcelink packages with old versions and don't benefit from the improvements that went into the product over the last years. They also bloat their restore dependency graph unnecessarily.
Consider emitting a warning when such a case is identified. Ideally this would be part of NuGet Package Pruning which is on since .NET 11 and is extensible. It's driven by an msbuild item list so the sourcelink packages could just be added to it in the Microsoft.NET.Sdk props/targets.
@tmat, cc @dsplaisted @jankratochvilcz
Referencing an old version of the sourcelink packages will make them win over whatever is inserted into the .NET SDK. The overall ability to reference sourcelink packages out-of-band is good but it shouldn't replace newer implementations that are part of the SDK.
The impact: Customers continue to reference sourcelink packages with old versions and don't benefit from the improvements that went into the product over the last years. They also bloat their restore dependency graph unnecessarily.
Consider emitting a warning when such a case is identified. Ideally this would be part of NuGet Package Pruning which is on since .NET 11 and is extensible. It's driven by an msbuild item list so the sourcelink packages could just be added to it in the Microsoft.NET.Sdk props/targets.
@tmat, cc @dsplaisted @jankratochvilcz