Our Requirement:
1) Developer should be able to find the dependencies of any selected assembly or file (class level) in the solution.
2) Integrate to build system. The tool should check for allowed/disallowed dependencies. The build should fail if there are disallowed dependencies.

Our Approach:
To satisfy the above mentioned, we tried to extend the NDepend.PowerTools by creating a new tool in the same solution.
In the tool class, we tried to use nDepend dlls to get the dependencies of all assemblies/classes in the solution. The input for the tool is the solution file.

Problem we faced:
After selecting our tool from menu and after selecting the solution file, we are not able to get all the assemblies in the solution.
The below mentioned method is not returning the actual assemblies which exists in the solution, instead its returning some random assemblies which are outside the solution.
IVisualStudioManager.GetAssembliesFromVisualStudioSolutionOrProject(IAbsoluteFilePath visualStudioSolutionOrProjectFilePath)

Although admittedly NDepend isn't a huge product, it would be helpful if there was a secondary deployment option which was just NDepend.Console.exe and its dependencies. No GUI tools, power tools, integration extensions etc. Just the absolute basics so that you can easy stick it on a build agent or in SCC as part of a tools folder without including stuff that a build agent would never use.

Of course, this now has its own problems as v7 seems to use an activation model whereas with v6 you could just include the license file to your agents. (Not to mention the console application for some reason has indirect references to the DevExpress WPF GUI components)

I would like to see another kind of dependency graph. It should be more like a map where dependencies flow from top to bottom or right to left. The difference is, that you can drill down from assemblies, to namespaces, to classes, to methods. All of this within one view.

For example: First I see a dependency graph containing all namespaces. When I click on namespace A, it shows me that this has dependencies to namespace B and C. Now I unwrap namespace B and see all classes and all dependencies from A to the classes, instead of the single dependency to namespace B. Then I unwrap class X and see all dependencies from A to specific Methods of class X.

Now we come to the planning. When I have a map of my architecture, I can move elements between containers. For example a class from one namespace or assembly to another. When I am satisfied with my new structure, I press a button and NDepend rearranges the code as I planned.

In addition to sharing custom rules between projects I want to be able to enable/disable rules among all my projects. I currently have 5 active ND projects, so if I want to turn off, for instance, "Nested types should not be visible" for all my projects, I have to go uncheck it in each project. Every time I tweak my rules, I have to go repeat these tweaks in all my ND projects.
Some sort of meta-project rules management would be an enormous effort saver.
In addition, once a set of "standard rules" are decided upon, it would be nice to be able to create new projects and have those rules be the default.

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.

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

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.