[Enhancement]: Improving dependency management

[HofmeisterAn]

Problem

Occasionally, we see Testcontainers users run into issues related to incompatible dependencies (dependency resolution). There are two common cases we've noticed:

1. Users of Paket often encounter this issue because Paket uses a different resolution algorithm.

As stated above, the algorithm defaults to resolving the latest versions matching the constraints.

As long as everybody follows semantic versioning and you define sane version constraints (e.g. within a major version) for your direct dependencies the system is very likely to work well.

Unfortunately, this approach makes NuGet package author A dependent on package author B (and everyone else) to strictly follow semantic versioning. Otherwise, users will run into issues. In theory, it's a good approach, but it heavily relies on perfect practices from everyone involved.

• Relates [Bug]: Docker.DotNet breaking change #814
• Relates [Bug]: Basic example from docs throw exception: Method not found: 'Docker.DotNet.DockerClient...' #1425

🚧 Paket provides a workaround:

To make your transition to Paket easier and to allow package authors to correct their version constraints you can have Paket behave like NuGet by using the ! prefix.

I don't quite understand the following part mentioned in the Paket FAQ. AFAIK, with the default dependency resolution mechanisms in place, developers can override and choose which version of a transitive dependency they want to consume:

Even more importantly: If two packages reference conflicting versions of a package, NuGet will silently take the latest version (read more). You have no control over this process.

2. Sometimes, Testcontainers users mix different versions of modules. For example:

<PackageReference Include="Testcontainers.MsSql" Version="4.3.0" />
<PackageReference Include="Testcontainers.PostgreSql" Version="4.4.0" />

Since these modules share the same underlying base dependency, this can lead to issues. Internal APIs might have changed in version 4.4.0 that aren't compatible with the previous version.

❗ The public APIs are still compatible, so users upgrading from 4.3.0 to 4.4.0 won't encounter breaking changes or any issues.

Are we supposed to pin the third party dependencies? What are we doing with the project references? AFAIK, this isn't supported OOB:

• Allow an upper limit Version for ProjectReference references in nupkg from dotnet pack to support semver NuGet/Home#5556
• Specify exact version of a project dependency NuGet/Home#5525

WDYT?

Solution

-

Benefit

Improve the developer experience. Developers shouldn't run into issues when a third party dependency releases a new version.

Alternatives

-

Would you like to help contributing this enhancement?

Yes