My tools as a web/"full-stack" consultant, part 2 of many: yak-shaving with NDependBy Benjamin Howarth on
I'd like to demonstrate the power of a fantastic tool I keep in my .NET architect's belt at all times: NDepend, a technical debt management tool for Visual Studio
In my last post I introduced the idea of Azure Cognitive Services, and in particular, the Computer Vision API for redacting text from images. The software I used to demonstrate this is NDepend, built by Microsoft MVP Patrick Smacchia. It uses the power of Roslyn & LINQ to help you write rules (with a number included out of the box) to tell you at a glance how much technical debt is in your project.
I'm currently working on upgrading this very website to the latest version of Umbraco, and I'll be using Merchello to run the e-commerce side of things. Whilst checking out the Stripe integration, I found an odd and unpleasant dependency. The Merchello.Core package bundles two payment providers in, Braintree and Paypal. The Strip package depends on Merchello.Core. Having a Stripe provider depend on Braintree & Paypal libraries, which will never be utilised, is pretty nasty.
If you've been into programming for a while, you'll recognise that I'm basically yak shaving at this juncture.
So, off we go! Now Merchello hasn't been updated to work with the latest Umbraco v8, but chatting with one of it's co-founders, there's a rough outline taking shape over on Github. Part of this is the idea that a separate Merchello.Umb DLL or namespace will be used to encapsulate any bridges to/from Umbraco v8, along with removing Examine as the underlying storage framework.
This is where NDepend really, really shines - telling you where the dependencies are in DLLs and giving you class-by-class, method-by-method breakdowns. It's fantastic for this sort of reorganisation, and even better, you can integrate it into your build pipeline so you can see over time how the code morphs into the rules you dictate (such as no direct Umbraco dependencies for anything except a potential new Merchello.Umb library).
Here's how I've started my analysis.
Download NDepend, you get a 14-day trial to start with, and install using the VSIX installer (it's not recommended to put it in your %ProgramFilesx86% directory, but I do anyway cause that's how I roll).
Boot up your project, under the new (and horrible) Extensions menu in VS2019, you'll find NDepend.
Click "New Project" and you'll be prompted to attach it to your current solution, and then select the DLLs you want to analyse. Note how the test assemblies are excluded.
Click "Analyze X .NET assemblies".
After a little while, a web page will open with this HTML file shown (this is where it fits neatly into a CI pipeline, there's CI support for TFS/Azure DevOps, Appveyor, and more):
You'll also be prompted with this screen if you want to do some more exploring using VS-integrated tools, which I love:
So, I want to analyse my assemblies. More importantly, I want to analyse which ones have dependencies on Umbraco DLLs, so I click "View Interactive Graph".
Nice graph, but that's only my 9 project DLLs (the option "View Application Assemblies Only"). Switching to "View Assemblies" in the top-left gives me ALL my dependencies too:
Eeeeesh, that's a mess. I want this to appear neater, let's move to the Dependency Matrix:
Aaaah, much better. Now I can start to analyse direct code dependencies from Merchello to Umbraco DLLs, and subsequently start extracting & abstracting them out over time.
Merchello v3 is in the pipeline, but much like my ideas on improving DNN to have a nicer UI getting rid of the crappy webforms parts, it's on a backburner.
Dear Reader, can you envision using NDepend in your projects? Let me know in the comments!