• The NDepend code model is now filled with properties and events thanks to the new interfaces IProperty and IEvent. Until now only accessors methods and backing fields were analyzed and some details like attributes tagging properties and events were missing.
• Those interfaces propose all members needed to query those code elements.

  public interface IProperty : IMember, IUser {
  
     IMethod GetMethod { get; }
  
     IMethod SetMethod { get; }  // Null if IsReadOnly
  
     IField BackingField { get; }
  
     IEnumerable<IMember> AccessorsAndBackingField { get; }
  
     bool IsReadOnly { get; }
  
     bool IsWriteOnly { get; }
  
     bool IsReadWrite { get; }
  
     IType PropertyType { get; }
  
     bool IsIndexer { get; }
  
     bool IsRequired { get; }
  
     bool IsExplicitInterfaceImpl { get; }
  
     bool IsAbstract { get; }
  
     bool IsNewSlot { get; }
  
     bool IsFinal { get; }
  
     bool IsVirtual { get; }
  
     IEnumerable<IProperty> OverridesDerived { get; }
  
     IEnumerable<IProperty> OverridesDirectDerived { get; }
  
     IEnumerable<IProperty> OverriddensBase { get; }
  
     IEnumerable<IMethod> MethodsUsingMe { get; }
  
     IEnumerable<IMethod> MethodsReadingMe { get; }
  
     IEnumerable<IMethod> MethodsWritingMe { get; }
  
     IEnumerable<IMethod> MethodsCalled { get; }
  
     IEnumerable<IMember> MembersUsed { get; }
  
     IEnumerable<IField> FieldsUsed { get; }
  
     IEnumerable<IField> FieldsAssigned { get; }
  
  }
  
  public interface IEvent : IMember, IUser {
  
     IMethod AddMethod { get; }
  
     IMethod RemoveMethod { get; }
  
     IField BackingField { get; }
  
     IEnumerable<IMember> AccessorsAndBackingField { get; }
  
     IType EventType { get; }
  
     bool IsExplicitInterfaceImpl { get; }
  
     // ... same as IProperty above
  
  }
  

• The API and code querying has been improved to support properties and events with:
  • Properties and Events queryable domains
  • IMethod.ParentProperty... IType.Properties... ICodeElementParent.ChildProperties...
  • Extension methods likes ChildProperties(this IEnumerable<IAssembly>...)
• Several default rules have been improved with this new APIs including
  • Avoid interfaces too big
  • Property Getters should be immutable
  • Properties and fields that represent a collection of items should be named Items
  • Collection properties should be read only
  • Don't use obsolete types, methods or fields...
• Properties and events can now be harnessed from any tool feature including: dependency graph;  dependency matrix;  code querying;  advanced search;  diff since baseline;  Visual Studio code editor and solution explorer extra NDepend menus;  decompilation with ILSpy;  suppressing an issue on a property or an event;  declaring a code rule in source code through a tag on a property or event...

The NDepend UI now adapts to Windows High-Contrast mode when this mode is enable.

• The Class Browser panel has been replaced with a Search Panel Tab. This way there can be multiple Class Browser instances and the user can filter by name or by kind of code element (Assembly, Namespace, Type, Method, Field, Property or Event).
• Class Browser as a Search Tab is possible thanks to the new search by name setting: Match all when empty string

• User can choose how a namespace hierarchy is displayed, tree or flat. In previous NDepend versions this global setting only applied to Class Browser and the Dependency Matrix. Since the Class Browser is now a special Search panel, the namespace hierarchy setting now only applies to the matrix. As a consequence it can be set from the matrix toolbar.

• When right-clicking a project, an assembly, a namespace or a type, the 6x menus under What was changed have been simplified to a single menu button Diff since the Baseline. This new menu generates a code query that lists all changes within the element.
• The screenshot below shows such a generated code query and list of changes within the project Nop.Core grouped by source files. Changes can be instead grouped per namespaces and classes.

• If the element is declared in a single file, like a class or a method, the source code diff tool is opened instead to compare both versions.
• In the screenshot above we can also see another v2023.1 improvement: When grouping elements matched by a query through directories and files, now the parent directories are grouped under a root directory (if any) and their paths relative to this root directory is shown (like .\Caching in the screenshot).

The .NET solution chooser dialog now also lists Rider and VSCode Most Recently Used (MRU) Solutions if these IDEs are installed.

• When installing the extension in Visual Studio a second time, VSIXIntaller.exe popped-up an annoying message box This extension is already installed to all applicable products. Not anymore.
• When installing or uninstalling the NDepend VS extension, the installation status is reflected by a check icon instead of showing a message-box about the success of the operation.

• In a query result, clicking the Expand or Collapse buttons now expands or collapses just on one grouping level when there are more than 20+ matched items. This simplifies browsing large results with hundreds or thousands of rows.
• A double click on one of these buttons leads to the behavior expand all or collapse all (recursive) as in previous NDepend versions.

New right-click menu Select Children available for projects, assemblies, namespaces and types. This menu generates a code query to browse and search within the concerned code element.
The screenshot below shows such a generated query. The search line has been uncommented to search for elements named like "cu" case-insensitive.

When a query is generated from a Search or Query Edition tab, the query generated panel now has a new button to go back to the tab that generated the query.

• The code metrics LCOM and LCOM HS have been improved to not take account of properties and events accessors and backing fields. This leads to less and more relevant matches for the rule Avoid types with poor cohesion.
• Type used from attribute constructors (like Foo in [MyAttribute(typeof(Foo))]) and used from attribute generic arguments (like Foo in [MyAttribute<Foo>]) are now seen as used by the type tagged, or the parent type of the member tagged. As a result the rule Potentially Dead Types doesn't match these types anymore.
• Type used from attribute tagging an assembly now has the new flag IType.IsUsedFromAssemblyAttributes. The rule Potentially Dead Types now relies on this new flag to avoid reporting such type as not used.
• The default rules Types with disposable instance fields must be disposable and Disposable types with unmanaged resources should declare finalizer now also take account of the interface System.IAsyncDisposable.
• The rule Attribute class name should be suffixed with 'Attribute' could match generic attribute classes, introduced with C# 11.
• The rules Structures should be immutable doesn't warn anymore about structures that have at least one fixed field, because such field cannot be declared as readonly.
• The rule Fields should be declared as private doesn't warn anymore about a field marked with the fixed keyword.
• The rule Override equals and operator equals on value types doesn't warn anymore about structures that have at least one fixed field, because such field is not meant to be compared.

• Go to Method, Field, Property or Event return Type now opens a new search tab to match the type.
• Global menu Source Diff since the Baseline now lists diff through the Search by Diff panel in a more browsable way.
• When a query result has only one column - the tree of code elements matched - the width of this column is set to the actual available width. This way no info gets unnecessary hidden because of a too short width.
• In VisualNDepend, new support for the keys Enter, F8 and Shift+F8 to go through matched code elements or issues within a query result.
• 2x new options in the dependency graph to eventually make it more readable:
  • to avoid prefixing a type name with its parent namespace name when not grouping types' boxes by namespaces
  • and to avoid prefixing a member name with its parent type name when not grouping members' boxes by types.
• A new option in the dependency graph lets the user zoom faster on deep graph. Alternatively, to quickly zoom on an element, click the Search button, search an item by name in the graph's items and double click it in the Search result.
• The Option Form is now larger for a better display.
• In the Dashboard panel, the trend chart range selected is now persisted across sessions. Also, now the range choices are shown within a popup menu for a clearer UI.
• In the Query Edition panel, the 3x checkboxes related to which sections of the query result are shown in the report are now grouped under a combo box. This makes the Query Edition panel clearer.
• In Query Result the statistic row is now hidden when it doesn't bring any value. These situations include when the query result is a scalar, when the query result is just a code element tree with no additional column or when expanding the sub-result view like when searching for types' coupling.

• New properties IField.IsRequired and IProperty.IsRequired to match C# 11 required members.
• New property IMethod.IsDefaultConstructor to match default constructors generated by the compiler on classes that don't have a constructor defined in source code.
  The default notmycode query Discard generated and designer Methods from JustMyCode now relies on this new property to make sure generated default constructors are not in the domain JustMyCode.
• When debt settings updates are persisted properly in a shared .ndsettings file, they are not saved anymore in the project file (.ndproj) to avoid sync issues.

10x bugs fixed in version 2023.1.0

12x bugs fixed in version 2023.1.1

• Code Quality Reporting from the GitHub Build: This GitHub Action lets run an NDepend analysis after each rebuild and explore results in a shared interactive HTML+js report (see some sample reports here ).
  Reports generated by the GitHub action contain links to code source hosted by GitHub.
• Try this new action: See the getting started documentation here. See the action on the GitHub marketplace here.
• Confidentiality: The NDepend GitHub Action runs only on the worker machine and zero data is shared remotely (source code, account settings or anything else) with ndepend.com or any other third-party.
• Build Fail: This Action can also fail the build upon some Quality Gate(s) failure (documentation link).
• Build Summary: An NDepend summary is available in your build summary to show the Quality Gates and issues status. Quality Gates are explained in the section above. (documentation link).
• Pull Request Quality Check: When an analysis is done after the creation of a Pull Request, the NDepend action adds a comment to your PR. This comment contains the quality gates status and the number of issues per severity, same presentation as the Build Summary in the screenshot above. And to have more details you can click on the link provided in the comment.
• Use a Run as Baseline: A previous GitHub run result can be used as a baseline to compare code and code quality against. (documentation link).
• Import Code Coverage Data: Code coverage data can be imported by the NDepend GitHub action to rule coverage ratios. (documentation link).
• Download Results from GitHub: With a Developer license, the standalone app VisualNDepend.exe or the NDepend Visual Studio extension can download the NDepend Github Action analysis results locally for further exploration (documentation link).
  The baseline result can also be downloaded from GitHub automatically when analyzing through NDepend.Console.exe if it is not available locally. (documentation link).

It is now possible to plug Jetbrains Rider or Visual Studio Code to open source code declarations.

Both IDEs can also be used to diff changes in source code made since the baseline.

This way the standalone executable VisualNDepend.exe can work side-by-side with these IDEs.

Untouched default queries and rules are now persisted by default through their query ids, or just query names for the ones that don't have ids. The benefits are twofold:

• NDepend project files weight much less (from 570KB to 70KB roughly)
• Untouched default rules and queries are automatically updated to their new versions when a new version of NDepend is used.

Any query change - like just adding a space - is enough to consider a default query as touched and thus, not persist it through its id.

Since v2018.2.0 dozens of false positive situations have been fixed in the default rule set. Your existing project will now benefit from these improvements. This is because any NDepend project created with NDepend version 2018.2.0 (released on the 11th September 2018) or higher, will see its untouched default queries updated to their id upon the next query change.

A project setting let's go back to plain-text storage mode for untouched default queries and rules. Notice that when an NDepend rule file (.ndrules extension) shared among several NDepend projects is created or modified, it inherits this setting from the current project setting.

An analysis result can now be identified with a human-readable identifier. Often such identifier will be a build number, a version or a milestone name.

The identifier is shown in the Dashboard for both the current snapshot and the baseline snapshot.

The new NDepend.Console command line argument /AnalysisResultId let's precise an identifier to the analysis result.

The NDepend APIs RunAnalysis() and RunAnalysisAndBuildReport() can now accept an identifier as an optional argument.

An identifier can be manually added to any existing analysis result file (.ndar extension). For example if the file name is NDependAnalysisResult_ProjectName_2022Oct11_13h14.ndar to assign the identifier "v2022.5.6" just rename to NDependAnalysisResult_ProjectName_2022Oct11_13h14_Id_v2022.5.6.ndar. As a consequence an analysis result identifier cannot contain characters that cannot fit in a file name \ / : * ? \" < > |. Also it must have a maximum of 64 characters.

All .NET 7.0 project's kinds can now be analyzed:

• ASP.NET Core
• Windows Desktop
• Blazor
• Console

Code containing some C# 11 raw string literals and C# 11 static abstract members can now be analyzed.

New property IType.IsVisibleOnlyInFile to detect when a type is declared with the C#11 keyword file (added with v2022.2.1).

The rules Avoid duplicating a type definition across assemblies, Avoid defining multiple types in a source file and Types that could be declared as private, nested in a parent type have been updated to avoid matching types declared with the C#11 keyword file (added with v2022.2.1).

.\net7.0\NDepend.Console.MultiOS.dll

.\net7.0\NDepend.PowerTools.MultiOS.dll

.\net6.0\NDepend.Console.MultiOS.dll

.\net6.0\NDepend.PowerTools.MultiOS.dll

The NDepend extension can now run within Visual Studio 2022 ARM from Visual Studio 2022 version 17.4.0 and onward.

Before NDepend v2022.2 an NDepend project could be modified when used on a machine different than the one that created it. This is because directories of the local .NET installation (including NuGet package directories) were referenced and these directories could change on a different machine.

Now only the .NET Profile is stored in the project and these directories are inferred from it. This makes the NDepend project immutable, no matter on which machine it is used. This makes it more convenient to store the NDepend project file in the SCM (Source Code Management).

There are contexts like Unity where the solution file can be re-generated. In such context an NDepend project cannot be attached to such solution.

This is why now per default, when a solution gets loaded in Visual Studio, the NDepend project that is in the same directory and that has the same solution file name (except the file extension) gets loaded even if it is not attached to the solution.

This behavior can be de-activated through a setting in Options > Visual Studio Extension Attach.

• New property IType.IsReadOnly to detect when a structure is declared as readonly.
• New rule Immutable struct should be declared as readonly (ND1914) to detect immutable structures that are not declared as readonly.
• In the Graph, Matrix and Metric views, the user can now choose if mouse-wheel provokes zooming (default and actual behavior) or vertical scroll in the new Options > Miscellaneous panel. Notice that Ctrl+Mouse-wheel let's perform the other action.
• A new option in the new Options > Miscellaneous panel now let's discard the ding sound played when showing an NDepend dialog that requires user attention (licensing matters, new version available, when about to close with data unsaved...).
• A new option in the Options > Miscellaneous panel let's prevent a tooltip to appear when hovering the NDepend circle in the status bar (both in Visual Studio and VisualNDepend).
• When using Rider to edit and diff source files, rider64.exe is also resolved in ToolBox directory like %AppData%\Local\JetBrains\Toolbox\apps\Rider\ch-0\2022.4167.23\bin\rider64.exe.
• When the debt settings are stored in a shared .ndsettings file, when changing some debt settings and then save them, there are only persisted in the .ndsettings file, the project file (.ndproj) is left untouched.

• Improvement of the heuristic that resolves an assembly path from a

  .csproj

  and

  .sln

  files. For example when a

  Directory.Build.props

  file contains

  <AssemblyName>$(SolutionName).$(MSBuildProjectName)</AssemblyName>

  the proper assembly name is now resolved.
• Assemblies resolution now also searches in

  Release

  directories if the assembly is not located under a in

  Debug

  like directory.
• Parsing the source code at analysis time is around 10% faster.
• Clustering large set of nodes on the dependency graph could create too large clusters. This has been improved to obtain more readable graph in any situation.
• In the dependency graph, when applying some filters that led to a graph with zero node, filters applied get modified to get at least one node. Now in this situation a message is shown to the user explaining this filter modification.
• New NDepend API method

  IProjectReport.RebaseSourcePathsInReport(string fromPath, string toPath, string lineSuffix)

  to rebase any file path location to something else like a GitHub source url. For example calling:

  project.Report.RebaseSourcePathsInReport(
      "root", 
      "https://github.com/ndepend/xy/blob/main", 
      "#L$LineNumber$");

  before calling

  project.RunAnalysisAndBuildReport();

  transforms

  C:\a\root\ClassLibrary\test.cs Line 76

  into

  https://github.com/ndepend/xy/blob/main/ClassLibrary/test.cs#L76

  .
• The rule

  ND1800: Methods that could have a lower visibility

  doesn't match anymore constructors of classes deriving from

  System.ComponentModel.EnumConverter

  , because these classes are instantiated dynamically.
• Analysis result storage is now rounded to seconds instead of minutes. Hence two analysis results obtained within the same minute can be stored side by side if the project setting Persist Analysis Result Frequency is set to Always.
• 3x new trend metrics related to code coverage overage on JustMyCode:
     Percentage JustMyCode Coverage
     # Lines of JustMyCode Covered
     # Lines of JustMyCode Not Covered
• The query

  Quality Gates Evolution

  now produces a more comprehensive result.

5x bugs fixed in version 2022.2.1

16x bugs fixed in version 2022.2.0

• Some rules and code queries result's cells match several items (like several classes or several issues). A new report setting allows to unfold up to N items in the concerned queries' results' cells. This setting is set by default on new projects with N=5.
• When the source file declaration(s) of a code element has been resolved at analysis time, per default there is a link to this declaration for each occurrence of the code element in the report. A new project setting is here to choose whether the linked path is absolute or relative to the project file location.
• Now code element's icon are shown in report by default.

• These new features are enabled by default on new projects and on existing projects.
• New flags in the enumeration NDepend.Project.ReportOptionsFlags: DontUnfoldMultiItemsCell DontShowCodeElementIcons DontLinkElementToSourceFile LinkElementToRelativeSourceFile
• In report "View Query Description" is now replaced with "View Quality Gate Description" and "View Trend Metric Description" on this kind of queries.

It is now possible to export a query result to JSON and CSV format.

New export options to:

• Unfold or not multi-items cell.
• Chose to prefix (or not) the exported result with the query body.
• Chose to suffix (or not) the exported result with the statistics for each column.
• Prefix code elements names in exported document like with C: for classes, M: for methods...

Right clicking a group in the Queries and Rules explorer panel can be used to export several queries' results to HTML, XML or JSON. When exporting dozens or hundreds of queries the UI remains responsive (instead of freezing as before) and an Abort button is now shown.

The last chosen export format is stored across session and re-used when opening a new query or search panel. Also for each panel restored from a previous session the export format is remembered.

New API extension method ExtensionMethodsQuery.ExportQueryResult(this IQueryExecutionResult, QueryResultExportDocumentKind) to automate exporting query result to the various formats (HTML, XML, Excel, JSON, CSV, Text).

(v2022.1.1 only)

NDepend can now read and process the .runsettings file's coverage exclusion and inclusion rules to obtain coverage statistics similar to the ones provided by other coverage tools. Here is the official Microsoft documentation concerning coverage exclusion through .runsettings file. A .runsettings file can be provided from Project Properties > Analysis > Code Coverage > Settings:

When analyzing an NDepend project that references a .runsettings file, some NDepend analysis logs provide details about the processing of these coverage exclusion and inclusion rules.

• Code coverage overall ratio computation has been changed and now better reflects the ratio shown by coverage tools.
• New property INamespace.IsGeneratedByCompiler to be able to filter out namespaces like Microsoft.CodeAnalysis or System.Runtime.CompilerServices that are generated by the compiler. This way such generated namespace doesn't clutter the dependency graph or matrix.
• New property IAssembly.CompanyName that gets the string value of the attribute System.Reflection.AssemblyCompanyAttribute, or empty string if this assembly hasn't such attribute.
• New property IAssembly.PublicKeyToken that gets the hexadecimal upper string value of the PublicKeyToken of the assembly, or empty string if this assembly is not signed.
• The heuristic to resolve an assembly from a .csproj project file now better handle <BaseOutputPath> value.
• The heuristic to resolve an assembly from a .csproj project file now also investigates child directories named b that might contain binaries.
• At analysis time, types provided in types and methods' generic parameters' generic constraints are now seen as used by the type (or parent type for generic method).
• When opening the source file declaration of a class or a method declared in a .razor file, the declaration is now opened at the right line.
• VisualNDepend or Visual Studio extension startup takes around 0.2 second less thanks to lazy instantiation of theme resources.
• The rule Class with no descendant should be sealed if possible now references this benchmark that measures performance improvements of using the sealed keyword.
• Typos fixed in rules description and API documentation.
• Clustering a large set of nodes on the dependency graph could create too large clusters. This has been improved to obtain more readable graph in any situation.
• A C#10 file-scoped-namespace now have its source file declaration(s) resolved at NDepend analysis time.
• NDepend now shows an error message box when executed from a WinRar temporary directory like C:\Users\{user}\AppData\Local\Temp\Rar$anything. This is because WinRar might corrupt the temporary installation anytime by deleting some files.
• A filter is shown on NDepend project's list (both on Start Page and on Ctrl+O dialog) when there is more than 10 projects.

A new ILSpy plugin is now provided to make NDepend and the free and open-source decompiler ILSpy interact both ways.

From NDepend to ILSpy: Just right click any assembly, namespace, class, method or field in NDepend or Visual Studio (with the NDepend extension installed). There are 3 new menus to:

• Select the code element in ILSpy
• Decompile the code element with ILSpy (Target languages: C# and IL)
• Decompile and Compare: the code element is decompiled from both the baseline assembly and the current assembly and both text files obtained are compared

It is possible to decompile large namespaces or even assemblies. This is especially useful to diff two versions of an assembly. If several classes are decompiled, they are aggregated in the text file in a consitent order, which makes the code review of changes possible.

ILSpy is a fast decompiler but C# decompilation of dozens or hundreds of classes can take a few seconds or minutes thus a progress dialog is shown with an Abort button.

From ILSpy to NDepend it is possible to:

• Show any code element on the NDepend dependency graph or matrix
• Analyze with NDepend one or several assemblies selected

The Visual Studio MRU (Most Recently Used) solutions picker dialog now properly resolves MRU solutions from VS 2022, 2019 and 2017.

It is now possible to provide a wildcard filter string to locate precisely coverage files in the specified directory. This way if coverage files are outputted in child directories randomly, like with Coverlet technology, it is possible to retrieve it.

• The notmycode query Discard generated Namespaces from JustMyCode now matches namespaces generated by the Blazor infrastructure. This fixes several issues found on such generated code.
• The rule Types with disposable instance fields must be disposable now checks that disposable classes of matched fields are instantiated within the parent class to avoid some false positives.
• The types compiled by the Razor infrastructure are now matched by the notmycode query Discard generated Types from JustMyCode to avoid some false positives on those.
• Usage of ref struct could lead to violate the rule Don't use obsolete types, methods or fields because the compiler tags ref struct with ObsoleteAttribute to avoid usage from older C# versions.
• In .NET 6, the class Program generated by top-level-statement could violate the rule Class with no descendant should be sealed if possible.
• When using record in .NET 6 the rule Do not hide base class methods could warn on the generated method <Clone$>() that is currently not marked by the C# compiler as generated by the compiler.
• The rule Avoid naming types and namespaces with the same identifier could match namespaces generated by the compiler whose name cannot be changed.

Analysis can now be executed out of the Visual Studio or VisualNDepend process and this is the default choice.

In-process analysis has very few performance and responsiveness impact. Nevertheless out-of-process is now the default choice to make sure Visual Studio productivity doesn't get affected at all.

Also when the analysis is executed out-of-process it is possible to abort it with the Abort button, shown in the Analysis Error List panel.";

It is still possible to fallback to in-process analysis from the Options > Analysis Settings panel.

The NDepend Visual Studio extension and VisualNDepend are now themed with the Blue, Dark and Light Visual Studio 2022 themes.

NDepend now have Visual Studio 2022 icons. In Dark theme, icon colors are now transformed to increase the contrast with the dark background.

In dark theme, now all right click menus are shown as dark.

14x bugs fixed in v2022.1.0

1x bug fixed in v2022.1.1

3x bugs fixed in v2022.1.2

2x bugs fixed in v2022.1.3

12x bugs fixed in v2022.1.4

The new ./net5.0/NDepend.Console.MultiOS.dll executable is a .NET 5.0 assembly that can be started with the dotnet command. It can be executed on Windows, MacOS and Linux to produce reports. The reports produced on MacOS and Linux are similar to the ones produced on Windows except that they are missing the graph/matrix/treemap diagrams. You can refer to the documentation: Getting Started with NDepend on Linux and macOS

NDepend.API.dll is now a netstandard 2.0 assembly. Thus the NDepend API can be executed within most .NET contexts including: .NET 5.0, 6.0, .NET Core 3.x, .NET Framework 4.7.2 and 4.8. In a non .NET Framework / Windows context, a few UI and Windows related APIs are not supported.

The open-source NDepend PowerTools now runs on MacOS and Linux thanks to the new NDepend.Console.MultiOS.exe .NET 5.0 executable.

NDepend on Windows now require the .NET Framework 4.7.2 or 4.8 installed to run. This is because to run also with .NET 5.0 most non-UI code has been migrated to netstandard 2.0 that works seamlessly with .NET Framework only since version 4.7.2.

NDepend.Console.exe can now be used to create an NDepend project on the fly. The first argument must be /CreateProject or /cp. The second argument must be the project file path to create.

Then at least one or several sources of code to analyze must be precised. A source of code to analyze can be:

• A path to a Visual Studio solution file
• A path to a Visual Studio project file
• A path to a compiled assembly file

See more details in the NDepend.Console.exe documentation.

NDepend.Console.exe can be used to register a license on a machine, or to start evaluation. Here are console arguments to use (case insensitive):

• /RegEval : Start the NDepend 14 days evaluation on the current machine.
• /RegLic XYZ : Register a seat of the license key XYZ on the current machine.
• /UnregLic : Unregister a seat of the license key already registered on the current machine.
• /RefreshLic : Refresh the license data already registered on the current machine. This is useful when the license changes upon renewal.

Each of these operations requires internet access to do a roundtrip with the NDepend server. If the current machine doesn't have internet access, a procedure is proposed to complete the operation by accessing manually the NDepend server from a connected machine.

• The NDepend project can reference some Linux style absolute path like /usr/share. However it is recommended to reference paths as relative to the project file location. This way the project is usable on various OS.
• Types and methods generated by C# top-level statements are shown as application code despite being flagged as code generated by compiler.
• New property IEnumerable<IType> IAttributeTarget.AttributeClassesThatTagMe { get; } to easily get all attribute classes that tag an IAssembly, IType, IMethod or IField.
• When attaching a new NDepend project to a VS solution, or when referencing a VS solution from an NDepend project, if the default project name filters (which is "-test") matches all projects of the VS solution, the filter is reset to avoid the situation where all projects to analyze are filtered-out.
• When analysing a Visual Studio solution with a filter that filters-out all its projects/assemblies, a new warning explains in plain-english the situation and that the filter needs to be modified.
• New API method FillIncremental() to compute a ICodeMetric<TCodeElement,TNumeric> object. With the API method FillIterative() (that already existed) only elements computed at iteration N are used to compute elements of iteration N+1. With FillIncremental() all elements computed until iteration N are used to compute elements of iteration N+1.
• A Technical-Debt breaking point value is a TimeSpan. Such value was formatted in number of days only, like 1000d. Now for values higher than a year the breaking point is formatted this way 2y 270d.
• Now code query result column can be typed with IAbsoluteDirectoryPath or IAbsoluteFilePath like in the query:

  from a in Application.Assemblies 
  select new { 
    a, a.VisualStudioProjectFilePath, 
       a.VisualStudioProjectFilePath
        .ParentDirectoryPath
  }

• When assemblies are resolved from a Visual Studio solution, IAssembly.VisualStudioProjectFilePath is now properly assigned to the project file resolved from the solution.
• Documentation of the rule Avoid namespaces dependency cycles has been improved.
• The rule Avoid referencing source file out of Visual Studio project directory now checks that the source file path and the project file path are on the same volume before emitting an issue. This avoids false-positive when the same project is used on several OS.
• It is now possible to drag and drop Visual Studio Solution Explorer types, methods and fields item (those under source file) to the NDepend dependency graph.
• New Power Tool r) .NET v5.0 and v6.0 installed Public API Changes that works on Windows, Linux and macOS.
• In the NDepend Project Properties, when browsing for an assembly, a Visual Studio solution or a directory, the default directory shown in the browse dialog is now among the ones referenced by the project. This directory is also updated upon directory selection or directory browsed chosen.
• The version 2021.2.1 proposes improvements related to NDepend.Console.exe and NDepend.Console.MultiOS.dll.
• (v2021.2.3) In the Graph Options, the user can optionally define a color that will be used to color the graph background. This possibility is useful for example to obtain a green screen overlay background.
• (v2021.2.4) When specifiying the project file path to NDepend.Console.exe (analysis or create project modes) it is now possible to provide a path relative to the current directory (obtained internally with System.Environment.CurrentDirectory) or just a file name in the current directory.

The NDepend extension now fully integrates within Visual Studio 2022.

The NDepend extension is still supported for Visual Studio version 2019, 2017, 2015, 2013, 2012 and 2010.

All .NET 6.0 project's kinds can now be analyzed:

• ASP.NET Core
• Windows Desktop
• Blazor
• Console

The new property IAssembly.TargetFrameworkName returns the target runtime targeted by an application assembly (like "net5.0", "netstandard2.1", "net461"...).

The new property IAssembly.TargetPlatform returns the target platform targeted by an application assembly (like "AnyCPU", "x64", "x86"...).

For .NET Standard assemblies whose parent directory wasn't named like "netstandardX.Y", in Project Properties the runtime shown was incorrectly shown as "netfx4". Now the proper runtime "netstandardX.Y" is shown in this situation.

When a third-party or framework assembly referenced by some application assemblies is not found at analysis time, it is now built from the references to it instead of being reported as not found.

Child namespaces, types, methods and fields of such referenced assembly are also resolved from their references found in application code.

The consequence is less warning. Also no matter the flavour of .NET targeted (.NET 6, Unity, Blazor, .NET Standard...) the analysis result is now always complete.

The new property ICodeElement.IsThirdPartyInferredFromRef can be used to list code elements resolved from reference and not from definition at analysis time.

ThirdParty.CodeElements.Where(c => c.IsThirdPartyInferredFromRef)

When a class c is sealed in baseline and not anymore (or vice-versa) the extension method c.WasChanged() now returns true.

When a class or an interface x implements in baseline an empty interface and not anymore (or vice-versa) the extension method x.WasChanged() now returns true.

When the list of attributes of a IAssembly, IType, IMethod or IField x is changed since baseline, the extension method x.WasChanged() now returns true.

When the type in a typeof(TypeName) clause in a method m is changed, the extension method m.CodeWasChanged() now returns true.

• (v2021.2.4) The rule Avoid having different types with same name doesn't warn anymore on usual WPF class name MainWindow.
• (v2021.2.4)The rule Methods name should begin with an Upper character could incorrectly warn on some methods generated for records like <Clone$>() but not marked as generated by the compiler.

20MB of DevExpress Winforms UI libraries have been replaced by a single 434KB library based on the OSS project DockPanelSuite.

As a consequence around 30MB of process memory is saved at VisualNDepend and Visual Studio extension runtime. These saved bytes represent both the discarded DevExpress DLLs weight and their versions JIT compiled to native.

Another benefit is that the downloaded zipped redistributable is now lighter, from 18.7MB to 13.9MB. Without the DevExpress libraries the redistributable should have weight less than 10MB but now it also embeds the Roslyn compiler to compile code queries and rules within a .NET 5.0 context.

32x bugs fixed in version 2021.2.0

4x bugs fixed in version 2021.2.1

2x bugs fixed in version 2021.2.2

2x bugs fixed in version 2021.2.3

4x bugs fixed in version 2021.2.4

6x bugs fixed in version 2021.2.5

Since NCrunch version 4.5.0 released in November 2020, NCrunch can export coverage data to OpenCover format XML files.

NDepend can now import coverage data from the OpenCover format XML files generated by NCrunch.

• Improved support for MSBuild variables: $(SolutionDir) $(Configuration)
• New support for MSBuild variables: $(MSBuildThisFileDirectory) $(MSBuildThisFileDirectory) $(MSBuildProjectFile) $(BuildPath) $(TargetFrameworkVersion) $(Platform) $(MSBuildProjectName)
• Improved support for .props files.

• If despite these improvements (above) NDepend still doesn't resolve some assemblies from a Visual Studio solution, it is now possible to resolve them through a recursive search under a root folder.
• Some hints can be proposed to guide the search.

• NDepend can now run on Windows machine with Federal Information Processing Standard (FIPS) enabled.
• Source file declaration is now resolved for records.
• New NDepend.API flag IType.IsRecord that is set for record classes.
• New NDepend.API flag IMethod.IsPropertyInit for property initializer method defined with the C# keyword init.
• .Views.dll ASP.NET Razor assemblies are now analyzed. However all their code elements are considered as notmycode since such assembly is generated by the compiler.

---

• New NDepend.Console.exe argument /DontPersistHistoricAnalysisResult to force not persisting analysis result.
• New NDepend.Console.exe argument /ForceReturnZeroExitCode to force returning exit code zero even when some quality gate are violated.
• When using the NDepend.Console.exe argument /InDirs with (or without) the argument /KeepProjectInDirs, a new info log is added to explain in plain-english which project's directory are kept (or removed).

---

• When opening a file in Windows Explorer, the file is now selected. Like for example in Project Properties > Code to Analyze > double click an assembly row
• When one or several elements are selected in the graph it is now possible to go back to the menu with application map shown when no element is selected.

• New rule in the Immutability category: Record classes should be immutable
• The query Types immutable should be tagged with ImmutableAttribute doens't match record anymore since most record classes are de-facto immutable.
• The rule Avoid namespaces with few types doesn't match anymore namespaces children of common infrastructure namespaces (like Services, Domain ...).
• The rule Float and Date Parsing must be culture aware doesn't warn anymore on methods in notmocode set.
• The rule Avoid partitioning the code base through many small library Assemblies doesn't warn on ASP.NET Core generated assemblies whose name is suffixed with .Views.
• The rule Avoid duplicating a type definition across assemblies doesn't take account of types defined in ASP.NET Core generated assemblies whose name is suffixed with .Views.
• The rule Types with disposable instance fields must be disposable now operates on JustMyCode types only. This way the rule avoids reporting unfixable issues on classes generated.
• The rule Do implement methods that throw NotImplementedException now operates only on JustMyCode.
• The rules Non-static classes should be instantiated or turned to static, Classes that are candidate to be turned into structures, Types that could have a lower visibility, Collection properties should be read only don't warn anymore on classes tagged with System.SerializableAttribute.
• The rules Methods should be declared static if possible, Methods that could have a lower visibility, Collection properties should be read only don't warn anymore on methods of classes tagged with System.SerializableAttribute.
• The notmycode query Discard generated Types from JustMyCode now match more Xamarin Resource type.
• The notmycode query Discard generated Types from JustMyCode now match EF Core migratuon class deriving from Microsoft.EntityFrameworkCore.Migrations.Migration.

See all details

NDepend can now fully analyze Xamarin applications for Android and iOS.

NDepend can now fully analyze the C# part of a Unity applications.

• The NDepend project can reference either one or several solution files generated by Visual Studio or one or several Unity assemblies usually named like Assembly-Csharp.dll.
• Detection of Custom Unity Installation by reading the registry key: HKEY_CURRENT_USER\SOFTWARE\Unity Technologies\Installer\Unity@Location x64

• Some Default rules have been updated to avoid false positives on Unity project:

  • The rule Potentially Dead Methods doesn't warn on methods of classes that derive from a UnityEngine class.
  • The rule Methods should be declared static if possible doesn't warn on methods of classes that derive from a UnityEngine class.
  • The rule Fields should be marked as ReadOnly when possible doesn't match fields tagged with 'UnityEngine.SerializeField'.
  • The rule Potentially Dead Fields doesn't match fields tagged with 'UnityEngine.SerializeField'.
  • The rule Instance fields naming convention all fields named like properties when analyzing Unity code. Often for high-performance reasons fields are used instead of properties in Unity projects.
  • The rule Fields should be declared as private is disabled when analyzing Unity code. Often for high-performance reasons public fields are used instead of properties in Unity projects.
  • The rule Fields that could have a lower visibility doesn't match fields in classes that derive from a UnityEngine class.
  • The rule Mark assemblies with assembly version is disabled when analyzing Unity code. You can still use the AssemblyVersionAttribute in Unity context as explained here.
  • The rule Avoid types with too many fields has a threshold of 30 instead of 15 for Unity projects. This is because Unity classes tend to hold many numeric and graphics states (color, shaders...).

• New Rules to inspect Unity code in the API Usage > Unity Category

  • Classes tagged with InitializeOnLoad should have a static constructor
  • Avoid using non-generic GetComponent
  • Avoid empty Unity message
  • Avoid using Time.fixedDeltaTime with Update
  • Use CreateInstance to create a scriptable object
  • The SerializeField attribute is redundant on public fields
  • InitializeOnLoadMethod should tag only static and parameterless methods
  • Prefer using SetPixels32() over SetPixels()
  • Don't use System.Reflection in performance critical messages

NDepend can now fully analyze Universal Windows Platform (UWP) applications.

It is now possible to use together:

• CQLinq expressions containing a code element name like HasAttribute("AttributeName") or DepthOfDeriveFrom("BaseClassName")
• with all kind of CQLinq expressions like NewerVersion() used to query the delta since the baseline.

As a consequence, powerful queries and rules exploring usage difference since the baseline can be then written: