In the NDepend Project Properties > Analysis > Baseline for Comparison > History Analysis Results, the user can choose where History Analysis Results are stored and the frequency of storage.These results can then be used as baseline.

It might happen that some History Analysis Results are lacking some important data, like coverage data or some specific source code data, because at analysis time this info was not available.

When such result is chosen as baseline, this has an important impact on issues computed and on the technical debt estimated. For now the user can remove concerned History Analysis Result by removing related folders as explained here:

http://www.ndepend.com/docs/technical-debt#NoCoverageDataOnBaseline

If you'd like us to provide a UI that would list History Analysis Results, that would show which ones doesn't have coverage data (or others flaws like source code not resolved), and that would let remove them, please vote for this feature.

We could also provide a filter at analysis time that would not persist an analysis result as history if it doesn't satisfy certain criteria (like coverage data available...).

The introduction of technical debt assessment and quality gates in NDepend 2017 is a very welcome addition. However, the scope of these features (and others like TFS integration and baselines) is restricted to NDepend. This scope is too narrow for those of us that make use of other rule sources such as FxCop, StyleCop, Code Cracker, Refactoring Essentials, OWASP Dependencies, SonarQube, custom written Roslyn rules et al. We would like to use NDepend's features but the scope means that it is only telling part of the story and unfortunately this isn't enough for it to be usable.

We would like NDepend to support a plugin model that allows us to feed it with violations raised by other rule engines. Armed with this feature we could use NDepend to see the whole picture.

When .NET Core assemblies and applications are built and packaged using dotnet CLI (e.g., "dotnet pack") the build output isn't a folder full of assemblies the way it was in classic .NET - it's a NuGet .nupkg file with the assembly (or full application) inside.

In the case of applications, this includes not only the entry point (e.g., "MyApplication.exe") but also any dependent assemblies required to make the app run. That even means all of the base framework assemblies ("System.Collections.dlll") - there is no reference to any installed .NET Framework. The dotnet CLI and runtime take care of that and the whole application is packaged. "Pay for play," as it were.

The idea for analyzing NuGet packages (https://ndepend.uservoice.com/forums/226344-ndepend-user-voice/suggestions/8619250-ability-to-analyze-nuget-packages) is somewhat related to this. If you add support for NuGet packages, this probably wouldn't be too much more of a step.

The idea for analyzing VS solutions (https://ndepend.uservoice.com/forums/226344-ndepend-user-voice/suggestions/4558407-reference-vs-solutions-from-the-ndepend-project) may be helpful for folks using Visual Studio, but you don't need that with .NET Core and the dotnet CLI - with those you may be looking at tooling more like Visual Studio Code, so it'll be interesting to natively support the analysis of packaged applications rather than assuming it'll work somehow through Visual Studio.

I would like to strongly advise the implementation in NDepend, of Halstead metrics that are already available in CppDepend. I frequently used the CppDepend maintainability index and other economic metrics to justify important and strategic refactoring.

I utilize other tools to measure the scope and monetary values of changes in C# code base. Yet, I apply other formulas, but without the same accuracy. To apply different formulas may induce contradictions that I must explain, which transform my project meetings almost to courses in software engineering metric and indicators.

To hold the same metrics on both CppDepend and NDepend provides uniformity and good comparison baseline. Implementing the Halstead metrics in NDepend would help a lot to earn credibility to justify projects financings.

There are currently project types for analyzing a project/solution and for analyzing a folder full of assemblies.

Much of my work lately has been in creating smaller, standalone "framework" sorts of packages on an internal NuGet feed that different applications can consume. There isn't "a master project" that has all of these packages working together; instead it's different combinations of the packages.

I'd like to be able to analyze all of these packages in a single report without having to either manually download them all or create a "fake" project just for the sake of referencing them.

One way to do this might be to allow analysis on a packages.config file. Add the packages you want to the file, specify a target framework, and have NDepend download the packages (and dependencies) and basically run the same process as "analyze a folder full of assemblies."

I think this will be even more interesting as DNX and the new project structure picks up momentum - everything becomes NuGet package references rather than direct project or assembly references.

It would be extraordinarily useful to include code churn metrics from source control. This would be an extremely helpful metric to help decide what parts of the codebase a team should look to start cutting down complexity, dependencies, and other issues.

I use code churn when it's available to help identify modules, classes, or methods that we should focus on. Items with high churn indicate they're getting touched a lot, which often indicates brittle sections of the codebase.

Since this is totally dependent on each particular source control system, it would make sense to start with only one or two of the most widely used SC systems in the .NET ecosystem. Maybe VSS? (KIDDING!)