The VSTS/DevOps plugin dashboard view on my laptop is really small with large lists.

It would really help if you provided a full-screen mode for portions of the reports like VSTS/DevOps does on other parts of the system.

For example, if I look at the Issues/Debt screen, and select "Critical Issues" on the left for example, the list can be quite long, but I can only see 10 items at a time with my laptop.

Not to mention that above that content there are two big divs that are probably wasting space.

One that says "Double click an issue to obtain more information" and the other stating the project name, build date, and baseline information. I'm pretty sure you could find a smaller way to show that info to give more space to the content below.

In a program and project, we might need to focus on certain aspects of the project, and postpone certains problems (or tag them as priority/under consideration/for further release).

The idea would be to create tags (like bags) to put rules / types / namespaces / functions to group or remove from a group one or several of these elements.

In that case, the project manager and the team can focus on the objectives, while keeping an eye on the overall objectives, for another timeframe. This would lead to multiple dashboards (on per tag for instance).

THis is part of project / program management, but it's necessar to integrate this to a tool such as Ndepend, which make the link between project management and everyday implementation / refactoring.

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...).

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.