DependenSee Documentation

DependenSee is a lightweight tool designed to create dependency graphs for .NET solutions. Key capabilities include:

• Dependency Graphing: Creates a visual graph of your solution's dependencies.
• Filtering: Ability to include or exclude specific namespaces to reduce noise in the output.
• Multiple Output Formats: Supports generating HTML (interactive), XML, JSON, and Graphviz files.
• CLI Integration: Can return output to STDOUT for piping into other tools, while sending errors and warnings to STDERR.

DependenSee v3 is being redesigned into three distinct components to improve extensibility and usability:

1. DependenSee Core: A standalone NuGet package (not a tool) that provides the underlying functionality. This allows developers to integrate DependenSee into custom scenarios that the CLI might not support.
2. DependenSee (CLI): An evolution of the existing CLI tool that acts as a shell for the Core package. Note that v3 is not backwards compatible with v2 CLI switches.
3. DependenSee Visualizer: A React-based application (delivered as a self-contained HTML file) used to view and interact with the dependency data.

By separating the discovery (Core/CLI) from the filtering (Visualizer), the tool allows you to run a single discovery pass and perform all filtering, searching, and customization within the browser without needing access to the original source code.

Limitations

• File Support: Only traverses .csproj and .vbproj files. Other file types are not supported.
• Analysis Method: Does not inspect compile results; it relies solely on the project structure.
• Scope: It is a simple dependency visualizer. It does not show type structures or relationships between specific methods/types (for those features, use NDepend or VS Code Map).

Privacy and Security

In the generated output, the tool uses project file paths as unique identifiers. While it attempts to use only the subdirectory structure to hide full paths, your local file structure (including your OS username in paths like C:\Users\<username>\...) may still be exposed. Inspect your output before distributing it publicly.

In v2, filtering was performed via CLI options during the discovery phase, which required access to the source code to re-run the tool with different filters.

In v3, the philosophy shifts to Discovery-first, Filter-later:

• Discovery: The CLI/Core performs a complete discovery run, emitting a comprehensive representation of projects, including Solution files and Solution folders.
• Filtering: All filtering (by folders, projects, project names, package names, etc.) is moved to the Visualizer frontend.

This allows you to distribute a single HTML visualization to users who do not have the source code, enabling them to interactively filter the data themselves.

To remove the DependenSee global tool from your system, use the following command:

dotnet tool uninstall DependenSee --global

DependenSee is a .NET global tool that requires the .NET 6 Runtime. You can install it via the dotnet CLI to make it available globally on your system.

It is also available on NuGet.

dotnet tool install DependenSee --global

To distribute a visualization that has pre-configured filters or customizations (like colors) applied by default, follow this workflow:

1. Generate: Run the CLI to generate the initial visualization.
2. Configure: Open the visualization in the Visualizer, set up your desired filters and customizations.
3. Extract: Export the configuration from the Visualizer as a JSON file.
4. Re-run: Run the CLI again, providing the path to this JSON file. The CLI will generate a new visualization that uses this JSON as the default filter state.

This allows for distributed documentation that shows a specific view of the dependency graph while still allowing end-users to change filters manually.

To generate a dependency visualization, run the tool by providing the root directory of your projects and the desired output file path.

Command Syntax: DependenSee <root/of/projects> <path/to/output.html>

For a full list of available command line arguments, run DependenSee without any arguments or consult the CLI documentation.

DependenSee root/of/projects path/to/output.html

DependenSee may log errors and warnings to the stderr stream. If you are capturing or relying on the standard output (stdout) and want to prevent stderr messages from appearing in your console or logs, redirect stderr to the system's null device using the appropriate command for your shell.

# Windows Command Prompt
Dependensee <args> 2> nul

# Windows PowerShell
Dependensee <args> 2> $null

# Linux/macOS Bash
Dependensee <args> 2> /dev/null

DependenSee has specific behaviors regarding filesystem links:

• Reparse points (including NTFS junctions): These are skipped by default. To include them in your analysis, use the -FollowReparsePoints flag. Note that they will not be followed if the target does not exist.
• Selective following: To follow specific reparse points while ignoring others, combine -FollowReparsePoints with the -ExcludeFolders flag to specify the paths you wish to skip.
• Symlink loops: DependenSee does not check for filesystem loops. If your symlinks contain loops, you must manually exclude them using -ExcludeFolders to prevent issues.

# Example: Follow reparse points but exclude a specific folder
Dependensee <args> -FollowReparsePoints -ExcludeFolders "C:\Path\To\Exclude"

If you encounter issues with the accuracy or permissions of your dependency analysis, check the following:

• Missing projects or duplicates: Ensure you are running the DependenSee command from the root directory of your projects.
• Access denied or missing folder errors: DependenSee assumes full access to all files and folders within the specified path. If the user account running DependenSee lacks permissions, you may see 'access denied' errors or find that certain folders are incorrectly reported as non-existent. Ensure the executing user has appropriate read permissions for the entire directory tree.