I'd love it if the Visual Studio add-in would highlight the location of the visual studio editor in the various NDepend views - particularly the code metrics tree map. I'd love to see where I am in code as I'm actively editing C# or VB .NET code.

I stumbled upon that properties in the API do not work correctly with managed C++ projects. For example IAssembly.VisualStudioProjectFilePath always returns null in case of a vcxproj or ISourceFile.Language always returns SourceFileLanguage.Other.
This is not about full support for managed C++ but basic things like the ones above would be great if they work when working in a heterogenous environment.

It would be great if you can suppress certain items from the analysis result and add a remark to why you suppressed them.

Some warnings might not be applicable to a certain item in the list, but if you cannot suppress them they will always count the item. Only other option is to fully disable the rule, but this might have unwanted consequences (like no warnings in the past).

A feature like: "Accept this violation" would be highly appreciated.

I use ReSharper a lot when coding, especially for refactoring. With the new Roslyn compiler, a bunch of these refactoring shortcuts also ship with Visual Studio and now can also be custom made ( https://www.youtube.com/watch?v=Ip6wrpYFHhE )

I found myself having to 'seal' 70 classes and I was looking for a NDepend function that does it automatically. Couldn't find it. So my idea is to provide auto-refactoring helpers for easy code fixes ( like sealing a class ).

NDepend code model should propose a getter IType[] IMethods.ParametersTypes to be able to write certain code queries and rules, like security related ones.

The UI can be overwhelming. I think it would be nice to have different profiles, e.g. for advanced and novice users.

The novice user should have a preset of settings which allow him only to see the basic features... just to create more overview.

Whereas the advanced user doesn't have to remove all the info messages/window.

It would be great if you can add a comment to a disabled rule. For some libraries we disable some of the rules and it would be great if we can put a remark why we disable a certain check. It would also be okay if we have to put it in the rule definition.

Just like in Visual Studio 2015, it would be nice to have a possibility to search in the options.

A lot of .NET people are starting to use AppVeyor a lot, it would be pretty awesome if you could integrate with it.

At this moment it is not intuitive and very hard to analyze Web sites with ndepend will be very nice if I could get site analyzed in few button clicks

It will be very nice if there will be ability to export dependency graph as SVG image rather than PNG, it definitelly will be less in size and as a bonus it will be resizeable without loosing quality

Using SonarQube, I see that they have a rule for flagging code that has been commented-out. Does this exist in NDepend, or could it be added?

Converters are seen as "Dead Code", but most of time, they are used as static resources into XAML. Is there a way to compute it ? Most generally, is it possible with static analysis to make some déductions including XAML code ?

When running ndepend on QHD display (e.g. 3200*1600), some screens have too small controls/content. E.g. Dependency Matrix, Dashboard

NDepend currently doesn't support code excluded from Dotcover test coverage analyses,resulting in discrepant results when Dotcover coverage filters are added. I propose adding support so that NDepend reports the same test coverage as Dotcover when content has been selected for exclusion.

NDepend's method variable count metric considers each exception catch statement to add another variable to the method's variable count. I can understand how those strictly would be considered function variables, but how is this helpful for code quality? Properly handling exceptions should not compete with keeping the method variable count low. Surely it is not bad practice to catch a number of specific exceptions. It seems like bad practice to create a separate wrapper function just to try/catch exceptions in the inner function. How would one refactor this to make it better?

A visual indicator indicates in the VS code editor for each code element (method, field, type, namespace) if it violates one or several rules.

From this visual indicator it is possible to jump to the code rule(s) violated)

The rule status would be updated asynchronously after 2 to 5 seconds (depending on the size of the code base) each time the user types and reach a compilable status.