About DependDB

Framework and library developers do not know which of their public APIs are actually used by other projects, they also cannot know in which way their APIs are consumed and are having a hard time to find out which effects a certain API change would trigger.

DependDB solves this problem by tracking dependencies between .NET projects:

• DependDB.Server stores all dependencies in a SQL server database and provides a web service to retrieve that information
• Downstream projects (e.g. applications) use DependDB.BuildProcessor to extract dependencies and automatically send them to the DependDB.Server
• Upstream projects (e.g. frameworks) use the DependDB.VisualStudioIntegration to get in-place usage information for any public type or member

It is very easy for downstream projects to integrate DependDB into their build process, so there is next-to-no overhead using DependDB. The benefit of course are fewer and easier changes of library APIs as upstream project developers know how their API is currently consumed - if a source code repository is provided they are even able to drill down into the source of individual usages.

DependDB tracks two different kinds of dependencies:

• Implementation dependencies (e.g. a class implements an interface or overrides a method)
• Usage dependencies (e.g. a method calls another method)

While usage dependencies are only tracked directly, implementation dependencies are also tracked indirectly as changes affect all levels down the derivation tree.

In addition projects can maintain several branches and versions in DependDB (a release branch might have other dependencies than the trunk). By default, only the latest version per branch is included in usage statistics. Branches can also be set to inactive if they do not intend to update to newer library versions anymore (e.g. hotfix branches) and library developers can therefore ignore these dependencies.