How NDepend is Resolving Assemblies

Introduction

As explained in the documentation Understanding NDepend Analysis Inputs the primary source of data for NDepend analysis are your application assemblies compiled in DEBUG mode. NDepend also resolves and analyzes third-party assemblies referenced by application assemblies.

From the application assemblies, NDepend resolves and analyzes also source files. Other artefacts like code coverage data can be also referenced.

The NDepend project file (.ndproj extension) can reference one or several Visual Studio solutions or projects from which, application assemblies are resolved.

The NDepend project file can also reference directly one or several application assemblies.

Resolving assemblies from one or several Visual Studio solution(s) or (projects)

The NDepend project file can reference one or several Visual Studio solution(s) and project(s) from which some .NET Application Assemblies to analyze are resolved.

Note that the set of application assemblies analyzed is the union of those Visual Studio solution(s) assemblies (159 resolved from OrchadCore.sln and 21 resolved from NopCommerce.sln in the screenshot below), and assemblies referenced by name (only one executable in row Other assemblies to analyze below).

Filtering-out some .NET assemblies of a Visual Studio solution

Typically you don't want to analyze all assemblies referenced by a Visual Studio solution, like test assemblies should be filtered-out. In the screenshot above we can see that one assembly is filtered-out from OrchadCore.sln and 4 are filtered-out from NopCommerce.sln.

By clicking the button Edit it is possible to edit one or several filters to filter-out Visual Studio solution assemblies by name. The default value for filter is -test. This is a negative filter prefixed by the minus character.

Zero, one or several positive and negative filters can be provided. An assembly is matched when it satisfies all positive filters and no negative filter.

Resolving assemblies of Visual Studio solution in a root folder

In most cases NDepend will resolve all DEBUG assemblies from your Visual Studio solutions and projects. Resolving from .props files and common MSBuild properties ($(SolutionDir) $(Configuration) $(BuildPath) $(TargetFrameworkVersion) $(Platform) $(MSBuildProjectName) ...) is supported.

However if your build is too complex, it is possible that some Visual Studio solution assemblies are not resolved. In this situation, in the Edit dialog you can check Resolve the assemblies of this Visual Studio solution under a Root folder (recursive).

Note that the root folder is referenced relatively to the folder that contains the Visual Studio solution or project. As a consequence, it must be on the same volume.

Folder Name Hints are separated by the vertical bar character |. Use hints both for:

• Orienting the research in the root folder of the Visual Studio solution or project assemblies
• Speed up the recursive research in the root folder

When recursively searching into the child folders of a folder, only the child folders whose name match a hint are inspected. If no child folder name matches a hint, they are all inspected. Hence it is important to choose the right hints to speed up the search.

Hints are case-insensitive. A hint can contain zero, one or several wildcard character *, that means anything.

The hints vertical bar separated default value is "Debug|bin|.bin|AnyCPU|x64|x86|v*.*|net*".

Only assemblies whose name match a Visual Studio project name (or the .csproj property <AssemblyName> if defined and different than project name) are matched. If several assemblies are matched for a project name, the preference goes to the one with an associated PDB file, or if many the one with the highest version, or if many the one with the shortest path in terms of number of characters.

Finally, a time-out must be provided to avoid a too long resolving time. Its default value is 10 seconds. With the right hints, in most cases resolution should take one or two seconds and you won't have to increase this time-out value, even on Visual Studio solutions that contain hundreds of projects.

Referencing directly one or several .NET assemblies

In addition to resolving some assemblies from one or several .sln or .csproj files referenced, the NDepend project file (.ndproj extension) can contains 2 lists of assembly names (case insensitive, without extension .dll .exe)

• One list for Application Assemblies Names,
• One list for Third-Party Assemblies Names. They inferred automatically from the Application Assemblies list, both those referenced directly and those resolved from a Visual Studio solution.

The NDepend project also contains a list of directories. To resolve assemblies, NDepend attempts to locate assemblies by name in the directories.

Notice in the screenshot below that directories containing NuGet packages and also those containing the .NET framework are referenced.

By default these directories are specified in the .ndproj project file as relative to the parent folder of this project file. However they can be specified also as absolute or prefixed with an environment variable in the tab Project Properties > Paths Referenced.

Heuristic used upon collision on assembly name

If several assemblies with the same name are found in several directories and/or from several Visual Studio solutions, here is the heuristic used to resolve the assembly to analyze:

• For application assemblies: the one with highest version
• For third-party assemblies: the one with the version found in application assemblies references
• else, the one with biggest file (in terms of bytes)
• else the one most recently modified
• else any, they are reported as all same.

If you are using the NDepend.API to create a program that builds NDepend projects, see the interface NDepend.Project.IProjectCodeToAnalyze.

Resolving .NET platform third-party assemblies referenced by your application assemblies

This list of directories also contain .NET Fx directories like C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319 or C:\Program Files\dotnet\shared\Microsoft.NETCore.App\5.0.0 to resolve third-party .NET Fx assemblies referenced by your application assemblies.

The .NET profiles supported are .NET 5.0, .NET Fx, .NET Core, Win RT and Silverlight. With time .NET 6.0, .NET 7.0 ... will be supported.

An heuristic is resolving the right version of referenced assemblies in the NuGet packages directories.

This heuristic is relying on .deps.json files (if found) to determine the referenced NuGet package names.