Charting the future direction of .NET Explorer

This product is what the Lean Startup™ methodology calls a "Minimum Viable Product." I am not currently charging for licenses, but rather looking for adventurous developers who are willing to give me feedback.

.NET Explorer is a highly visual tool, and frankly quite fun. Never before have you been able to quickly visualize software architect of both your own projects, and all the NuGet packages that you use. If you are interesting in tring it out an willing to give me feedback, please email me at mvp@softwaredog.net and I'll send you a license.

I am limiting this phase to 200 intrepid programmers.

As of the launch, this page is a place-holder so you know what I am thinking about. As I receive feedback I will amend and rearrange this page to reflect where power-users want to go.

This list is broken down by feature, and within each feature are the items I think are important. I will enrich the format as I acquire feedback.

Initial focus is on bug fixing and making sure current features are rock solid. Please use the Feedback navigation to report problems, or to suggest improvements.

A lot of things could be done here:

  • Search directories of interest. Search a large number of files will require indexing. Which database you would want or tolerate is up for discussion.
  • Make search more asynchronous and cancelable.
  • New search grammar to find assemblies rather than types.
  • Context menu to add search results to Analysis Set or Favorites.
As the workhorse of the application, there are many things that can be done here.
  • An Assembly Dependency network. For example, if we examine Dapper.dll (the .NET Standard 2 version), we would see that it depends on netstandard (2.0.0.0), System.Reflection.Emit.ILGeneration, and System.Relection.Emit.Lightweight. Of course, the transitive references would also be shown, and hopefully there are no cycles :-).

    However, certain DLL's such as netstandard or System.Runtime are referred to, but the actual type does not live there, it lives somewhere else (type forwarding). Showing this information graphically can help developer's learn how complex the .NET run-time really is.
  • Network visualization engine. I am currently using vis-network, and JavaScript library forked off an older vis.js library. So far as I know, it has the best ability of competing JavaScript libraries to customize the look of nodes (I use raw HTML canvas primitives).

    That is not to say another library could be offered along side (that is, vis-network does not go away) the current visualization. Both sigma.js/graphology.js and cytoscape.js are extremely powerful graph visualization libraries, and can probably handles graphs with several thousand nodes more quickly.

    graphology.js itself gives ability to add "Social Networking" metrics to .NET Explorer (these metrics can be done in C# as well). This segues into the next point.
  • Export to social network visualizers. If you are a "data sciency" programmer, then you might wish to use a third party application such as Gephi, Cytoscape or SocNetV, or perhaps use a Web service such as Tableau.

    It is not significantly hard to provide the network data in Gephi, GML, GraphML or CSV formats.