About DependDB

DependDB tracks dependencies between .NET projects, such as an application using a library, across versions.

• A DependDB Server stores all dependencies in a SQL Server database
• Downstream projects (e.g. applications) use DependDB Analyzer to extract dependencies and automatically send them to a DependDB Server
• Upstream projects (e.g. libraries) use the DependDB Visual Studio extension to get in-place usage information for any public type or member

Problem

Many open source projects declare most of their stuff public by default (in contrast to Microsoft products, where APIs are more consciously designed and everything else is internal by default). This has two effects:

1. Developers using these libraries get a lot of power to adapt them to their needs, but also the responsibility to distinguish between stable APIs and obscure internals that might change in the next release.
2. The library developers cannot tell what the downstream effects of a certain change are.

DependDB addresses the second point.

Solution

Downstream projects can configure their builds to send usage information to a DependDB Server maintained for one or more upstream projects. They only need to start the DependDB Analyzer as part of their build process (preferably in a Continuous Integration environment). The DependDB Analyzer will then create a list of dependencies and send them to the DependDB Server.

Developers of the upstream project can then use the DependDB Visual Studio extension to get up-to-date usage statistics for every single public type or member within their project, and can even drill down into individual usages if the upstream project provides a path to a source code repository.

DependDB tracks two different kinds of dependencies:

• implementation (e.g. a class that implements an interface or overrides a method)
• usage (e.g. a method calls another method)

Implementation dependencies are tracked directly and indirectly, usage dependencies only directly.

Some special features:

• Downstream projects can maintain several branches in DependDB if they are still actively maintained (a release branch might have other dependencies than the trunk).
• By default, only the trunk of each downstream project is included in statistics for the upstream developer.
  • Rationale: Release branches will usually not update to the most current version of upstream projects.
  • Dependencies are tracked across versions, assuming that all downstream projects that use DependDB will eventually want to upgrade to the latest version of the upstream library.
  • A downstream project can chose to include other branches by default (e.g. feature branches)
  • In a future version, upstream developers can chose to include all projects referencing a specific version of the upstream library. (This is necessary when a hotfix is developed that is supposed to be included in release branches of downstream projects. However, in these situations changes to public APIs are rather uncommon.)