NDepend

Improve your .NET code quality with NDepend

The continuous adaptation of Visual Studio extensions

One could think that developing an extension for a two-decades+ product as mature as Visual Studio is headache-less.

Not really. Visual Studio is a big big beast used by millions of professional developers daily. Versions after versions Microsoft is spending an astounding amount of effort to improve it and make sure it respects the latest standard in terms of dev platforms, IDE features, usability and performance.

This implies a lot of deep changes and all VS extensions must adapt to these changes … or die. Most of this adaptation efforts come from the support of new platforms (.NET Core, Xamarin, upcoming .NET 5…) but here I’d like to focus on VS integration recent changes.

Deferred extensions loading

On Monday 11th December 2017 all VS partners received an mail announcing VS package deferred loading, also referred to extension asynchronous initialization. In this mode VS extensions are loaded after VS startup and initialization. As a consequence VS startup is not slowed down by extensions.

Implementing this scenario required serious changes described here but this deferred loading scenario became mandatory only with VS 2019.1 (16.1) released this spring 2019, around 18 months later after the initial announcement. VS extension ISVs got plenty of time (and plenty of high quality support from Microsoft engineers) to implement and test this async loading scheme.

VS2019 Extensions Menu

In February 2019, we were developing the support of NDepend for VS 2019 and were downloading the latest VS2019 preview, installed our NDepend extension and immediately noticed there were no more NDepend global menu? After investigation we saw our NDepend main menu, and other extensions menus, under a new Extensions menu –with no possibility to get back extensions menu in the main bar–.

Visual Studio 2019 Extensions Menu

This change impacts millions of extensions users and hundreds of partners ISVs but has never been announced publicly ahead nor debated. As an immediate consequence someone asked to get rid of this new Extensions menu and this generated a long list of complains.

I guess this major (and blunt) change was provoked initially by the VS2019 compact menu look, but I am not sure: even on a 1920 pixel wide monitor (DPI 100%) there is still plenty of width space to show extension menus.

Visual Studio 2019 Compact Menu

Sometime in April 2019 someone anonymously published on the discussion the link to a new extension to put back extensions main menus in the main bar.

Getting back Extensions in Main Menu

I guess the VS APIs used to achieve this magic are not well documented, hence we can wonder if this initiative comes from MS or not? At least now users can get back their extensions menus in the main bar. But the Extensions in Main Menus extension has been downloaded only 800 times in around 3 months. It means only a tiny subset of VS extension users are aware of it and are actually using it.

Personally I still have hope Microsoft will reconsider this move and will embed a similar option in a future VS version to let the users chose which features (out-of-the-box VS feature or extension feature) deserves a no-brainer/main bar access or not.

VS2019 Optimize rendering for screens with different pixel densities

We published NDepend v2019.2.0 on 14th March 2019 with proud support for VS2019 and .NET Core 3. Two weeks later a user reported severe UI bugs we’ve never observed. The repro scheme was easy:

  • install .NET Fx 4.8,
  • enable the new VS2019 option Optimize rendering for screens with different pixel densities
  • run VS2019 with the NDepend extension in a multi-monitors environment with various DPI scale for each monitor
Optimize rendering for screens with different pixel densities
Optimize rendering for screens with different pixel densities

We then discussed with VS engineers. They pointed us to this documentation and kindly offered quite a few custom advices: Per-Monitor Awareness support for Visual Studio extenders

Actually this change is pretty deep for (the tons of) WPF and Winforms controls rendered in the Visual studio UI. This took us time but we just released on July 3rd 2019 NDepend v2019.2.5 with full support for this Optimize rendering for screens with different pixel densities option. This required quite tricky fixes and we’d wish we have had a few months to adapt to this major breaking changes as we had for deferred loading explained above. As far as I know extensions ISVs were not informed in advance. On the other hand I’d like to underline the awesome support we got from Visual Studio engineers (as always actually) thanks again to all of them.

I noticed that Resharper pops up a dialog at VS2019 starting time (not sure if they got all fixed at the time of writing).

Resharper Message related to Optimize rendering for screens with different pixel densities

I also noticed that up to VS2019 16.1.3 there were still some bugs in the VS UI, see the Project Properties and Diagnostics Tool windows below. I just tried with 16.1.5 and it seems fixed.

VS 2019 16.1.3 UI issues (now fixed)

My point is that this great improvement (Optimize rendering for screens with different pixel densities) should have been highlighted ahead during VS2019 preview time to avoid a wide range of UI bugs experienced by users during the early months of VS2019 RTM.

What can we expect next?

With .NET 5 public announcement on May 6th 2019 the .NET community now knows that sooner or later most of .NET Core or .NET Fx applications will have to be migrated to benefit from latest innovations and improvements.

Hopefully .NET Core apps migration will be quite straightforward since .NET 5 is .NET Core vNext. But .NET Fx apps migration will be (more or less) painful. Although WPF and Winforms desktop APIs are already supported by .NET Core 3, some others major APIs are not – and won’t be – supported (ASP.NET Web Forms, WCF, Windows Workflow, .NET Remoting, AppDomain…).

For too complex migration plans here is the Microsoft recommendation: What do you do with your older applications that you are not spending much engineering time on? We recommend leaving these on .NET Framework. (…) .NET Framework will continue to be supported and will receive minor updates. Even here at Microsoft, many large products will remain on .NET Framework. There are absolutely no changes to supportĀ and that will not change in the future. .NET Framework 4.8 is the latest version of .NET Framework and will continue to be distributed with future releases of Windows. If it is installed on a supported version of Windows, .NET Framework 4.8 will continue to be supported too.

Visual Studio 2019 is still running in a 32 bits process upon the .NET Fx 4 CLR with a massive WPF based UI and some COM usage.

Can we expect VS2019 to run on .NET 5 sometime in 2021? or in a later version? or never?

Only the future will tell but I hope extension VS ISVs will be advised ahead to anticipate the migration and continue to offer a seamless integration experience to users.

Simplifying a Visual Studio extension menu: A Case Study

NDepend version 2019.2.1 has just been released. This new version proposes a simplified menu for the NDepend Visual Studio extension.

Before going further I underline that we didn’t get rid of the standard menu, the user can switch back and forth simplified and standard menu within a single click. There is something in UI that all users worldwide dislike: don’t force a new UI just for the sake of it.

The simplified menu is shown per default on machines that never ran NDepend, else the standard menu is shown. Here is a view of the simplified/beginner menu vs. the standard/advanced menu.

NDepend simplified/beginner menu vs. standard/advanced menu

We introduced a simplified menu because we think that trial users and beginner users will benefit from it. Having most features available through a single level menu certainly makes the product features more discoverable.

More and Tools popup menus

A More… popup menu is here to show features and actions that are typically used less often. It is a UI trade off to force an extra-click to access these actions:

More Actions Menu

The Tools popup menu is an opportunity to switch to the advanced menu, and see the NDepend Start Page. It is also good to discover NDepend tooling outside Visual Studio, the standalone VisualNDepend.exe, NDepend API and OSS Power Tools, Azure DevOps extension and others Continuous Integration possibilities:

Tools Menu Actions

Opportunities to lean up the user experience

Having a simplified menu is also an opportunity to encourage the user to do some configuration steps. For example in the first screenshot we have the Explore Code Coverage button. With NDepend the code coverage by tests of a code base can be harnessed in multiple ways as explained here. But to harness code coverage data the user has to import it first. Hence, per default an Import Code Coverage button is shown to the user and the Explore Code Coverage button is shown only upon data imported.

Another important NDepend feature is comparing against a baseline. As far as I know NDepend is the only Visual Studio tool that lets the user diff the actual code base against a baseline. The user can then focus on new issues since baseline, or diff-related issues like API Breaking Changes or Code Smells Regression. The baseline can also be used to review code changes since the baseline. When NDepend analyzes a large legacy code base, letting the user focuses on new issues since the baseline is a very important facility to avoid letting the users lost in the prioritization of thousands of issues.

Per default the baseline is set to the first analysis result obtained. It means that the first time the user runs an analysis on a code base, this first analysis result is used both for the actual snapshot and the baseline snapshot. In this situation, when the user clicks the buttons New Issues since Baseline or Diff since Baseline, there is nothing to show. Thus we take a chance to show an informational message box that explains this no-diff situation. Doing so avoids the user being stuck with a no-result action or even worse, a button disabled with no obvious reason. We also hope these explanations will motivate the user to work on changes and then re-analyze to see what NDepend has to say about the new changes.

Having a single level menu just became mandatory

Another point to underline is that having a single level VS extension menu just became mandatory. Visual Studio 2019 just introduced the Extensions top level menu and extensions cannot have their top level menus anymore.

Visual Studio 2019 Extensions Menus

This move adds an extra click for accessing each extension feature. This extra click represents a UI regression for the millions of VS extensions users and de-facto discards features accessible only through a nested sub-menu. This move was unexpected because it solves a UI problem we (as a VS extension provider) have never heard of: having so many extensions menus that it becomes a cluttering problem. The only right way to solve such problem would be to let the user choose which extension have their top-level menu and which extension lies under the Extensions menu. An extension menu should be top-leveled by default upon installation: when a user installs an extension the goal is to spend the next minutes or hours trying it and using it. In this context it doesn’t make sense to put the extension menus in a second-zone, doing so degrades the so precious and fragile FTUE First-Time User Experience. A VS extension doesn’t get a second chance to offer a first impression to a trial user.

Several big names in the VS extension industry have already complained about this move here. You can vote and comment now because apparently Microsoft will monitor this thread only till mid May 2019.


 

We hope this simplified menu will help trial and beginner users getting started with all the NDepend goodies. Certainly some seasoned users will also prefer this less cluttered menu style. If you have comment or ideas to improve more let us know.

On forced UI change you can read further this 2012’s Scott Hanselman post Who moved my cheese?

People don’t like it when you move their cheese. They are just trying to get through the maze, they have it all under control and then, poof, someone moved their cheese. Now it’s a huge hassle to find it again. Change a hotkey or the case of the menus and all heck breaks loose.