NDepend Blog

Improve your .NET code quality with NDepend

Will Visual Studio Be Migrated to .NET Core and Become Multi-Platform?

April 22, 2024 7 minutes read

Will Visual Studio Transition to .NET Core and Become Multi-Platform

I came across comments on a recent Reddit post and thought it would be intriguing to analyze the DLLs of Visual Studio 2022 (version 17.9.6) using NDepend. This analysis could reveal interesting details about how closely VS 2022 adheres to the old .NET Framework, Windows native calls, and WPF and WinForms

Full-fledged version of Visual Studio for Windows still based on the old .NET Framework, Do you think Microsoft will eventually rewrite it using the new cross-platform .NET version to provide a fully-featured Visual Studio for macOS and Linux as well?

Notice that there are two distinct questions:

  • Will Visual Studio Be Migrated to .NET Core? (but still remain Windows-centric).
  • Will Visual Studio Be Multi-Platform?

Disclaimer: For nearly two decades, I’ve been the creator and lead developer of NDepend, a tool that functions both as a Visual Studio extension and a standalone app that can collaborate with VSCode and JetBrains Rider. NDepend also integrates into CI/CD pipelines to deliver interactive web reports on .NET code quality and security. We’ve collaborated with many Visual Studio engineers over the years, who have provided invaluable assistance, though we have no insider information. This post is based purely on observable facts and speculations derived from them.

Visual Studio: A Colossal .NET Code Base

To analyze the Visual Studio code base, I set up a new NDepend project referencing DLLs located in the folder C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE and its subfolders. I then manually pruned DLLs such as mscorlib and Newtonsoft.Json that, although present in these folders, are not directly related to Visual Studio. The results were as follows

  • 1.609 assemblies DLLs (70 EXEs, 1.539 DLLs)
  • that contain 239.223 types
  • that contain 1.954.404 methods and 905.143 fields
  • for a total of 40.998.296 IL instructions. Obviously we don’t have access to source code so we’ll stick with # IL Instructions to measure code size. In average a statement compiles to 7 IL instructions so the analyzed code base contains roughly 5.8M statements.

Here is a dependencies graph of the 754 assemblies whose name matches *VisualStudio* (click it to see a larger image) :

Visual Studio DLLs Graph

Native Calls in the Visual Studio Code Base

With this C# LINQ code query we obtain 9.769 native methods (Platform Invoke):

It is interesting to look at the distribution of native calls in Visual Studio DLLs with this query:

Here are the findings. They indicate that core components of Visual Studio, such as the debugger, team foundation, the profiler, and the shell, heavily depend on native calls.

Visual Studio Native Calls

Visual Studio Usage of WPF and Winforms

Let’s query the Visual Studio classes and structures that are using WPF or Winforms:

We obtain 12 615 types. Looking at these types matched in the metric view (in blue) provides insight into Visual Studio’s reliance on Windows-centric UI frameworks, More importantly, it appears that WPF and WinForms are being utilized broadly across various projects. This suggests a lack of concerted effort to limit UI dependencies to specialized projects to facilitate greater abstraction from the code.

Visual Studio Adherence to WPF and Winforms

Target Framework of Visual Studio DLLs

This code query identifies assemblies compiled against any version of the .NET Framework, ranging from 1.0 to 4.8.

Here are the results:

Visual Studio NetFx Assemblies Ex

In terms of IL instructions, 76.2% of the Visual Studio code is compiled against the .NET Framework. The remaining 23.8% is compiled against .NET Standard 2.0 or a version of .NET Core such as net6.0, net7.0, or net8.0.

Visual Studio NetCore and NetStandard Assemblies

.NET Standard 2.0 code can run within a .NET Framework or .NET Core process. However, .NET Core assemblies run within background processes spawned by devenv.exe, the main Visual Studio process which is a .NET Framework process.

Visual Studio Task Manager

What Can We Conclude?

Will Visual Studio Be Migrated to .NET Core? (but still remain Windows-centric).

First, let’s go through why would it be beneficial:

  • Visual Studio would benefit from all the performance gains brought by the .NET team over the year
  • Certainly, developers working on Visual Studio are somewhat frustrated with working with a framework frozen in 2019.
  • Visual Studio’s main process operating on the old .NET Framework projects an image of an outdated, legacy product to the community

Shifting Visual Studio 2022 to x64 required a tremendous amount of work. Similarly, upgrading the hundreds of projects to .NET 8 (or higher) will also be a significant undertaking. However, considering that .NET Core fully supports native calls, along with WPF and WinForms, the scope of this migration is significantly bounded.

Currently, it’s not a secret that DevDiv is heavily focused on integrating AI enhancements to boost .NET developer productivity. However, given the advantages and feasibility of running Visual Studio on .NET Core, it’s reasonable to anticipate this change in the next version of Visual Studio, or the one following. Once again, this is just speculation and should not be considered as insider information, it is not.

The UI challenge to make Visual Studio Multi-Platform

Adapting Visual Studio to work on Mac OS and Linux presents a unique challenge. WPF and WinForms are primarily designed for Windows. However, Avalonia XPF aims to enable WPF applications to run on multiple platforms. Similarly, Mono WinForms provides a multi-platform port of WinForms. Publicly, Microsoft has consistently dismissed any expectation of migrating these UI frameworks to other operating systems. Additionally, these alternative technologies demand substantial manual effort. Considering the extensive use of WPF and WinForms within the Visual Studio code base, it seems unrealistic to expect that Visual Studio will become multi-platform as-is one day.

What about transitioning Visual Studio to a fully featured .NET cross-platform UI framework?

  • Firstly, which framework would be suitable? MAUI, perhaps? Personally, I haven’t worked with MAUI and thus have no opinion on it. Yet, MAUI appears to receive considerable criticism—perhaps the detractors are just more vocal? I’m not sure. In the main Reddit post comment states “I don’t think that they are mad enough to use MAUI, and web-technologies also look like a bad fit due to performance considerations.”. Let’s mention that nowadays there are two popular .NET cross-platform UI frameworks: Uno and Avalonia. Both are non-Microsoft initiatives and both seem preferred to MAUI by the community (again just my feeling based on real people reddit comments).
  • Secondly, as we saw the scale of this task is so vast that I question whether it will ever be accomplished.

Keep in mind the UI challenge is just one aspect. Many core components of Visual Studio, especially the debugger, depend heavily on native calls, presenting their own set of migration challenges.

Will Visual Studio Be Multi-Platform?

Ultimately, what are the advantages of making Visual Studio compatible with Mac OS and Linux? Microsoft has phased out Visual Studio for Mac, while simultaneously investing heavily in enhancing .NET programming on VS Code. The message from Microsoft is straightforward: For a comprehensive IDE for .NET programming, use Visual Studio on Windows. For other platforms, the powerful and free source code editor, VS Code, is available.

Nonetheless, Microsoft is aware of the success of JetBrains Rider, a commercial, multi-platform .NET IDE. For the time being, however, VS Code remains Microsoft’s solution for multi-platform .NET programming. As a Reddit comment underlines: “The distance between VS and Linux is much larger than the distance between VS Code and a full IDE.”. Another comment speculates: “Where I think they’re really going is trying to use the C# Dev Kit in VS Code as an excuse to port their Intellisense and several other “secret sauce” features to be cross-platform. Once that’s done, I think they’re going to build a new, cross-platform VS on top of that version of VS Code, sort of how like Microsoft Edge is a fork of Chromium.”

In summary, it is unlikely that Visual Studio will become multi-platform anytime soon.

Our Strategy as a Visual Studio Extension Provider

In 2021, to address the challenges of .NET Core and multi-platform compatibility, we migrated the majority of our code base to .NET Standard 2.0. Currently, 68.7% of our code is capable of running on .NET 8.0, 7.0, 6.0, or .NET Framework. We wrote a detailed post about this challenge: 5x Lessons Learned from Migrating a Large Legacy to .NET 5/6

This adaptation enables the CI/CD components of our product to produce HTML interactive reports across various platforms. We offer users the option to run the analysis on .NET 8.0, 7.0, or 6.0. Each corresponding folder—net8.0, net7.0, and net6.0—includes a console executable that initiates the appropriate framework and then calls the .NET Standard 2.0 code for analysis and report generation.

NDepend Deployment

Meanwhile, both the Visual Studio extension and the standalone UI VisualNDepend.exe remain compiled against the .NET Framework. For the Visual Studio extension, this is a requirement. For VisualNDepend.exe, it is convenient because – unlike .NET Core – the .NET Framework comes pre-installed on all Windows machines.

During this migration, we abstracted 42% of the UI code from any specific UI framework. This way we facilitate a smoother transition when we eventually switch to a multi-platform UI framework. In the meantime, we have invested in enhancing the existing UI and significantly improving the HTML interactive report as well. Given that more applications are transitioning to the browser nowadays, developing a fully usable and navigable web presentation of NDepend results is a strategic move for the future.

NDepend UI Infrastructure Ex

 

 

 

Comments:

  1. Jeff Jones says:

    “DevDiv is heavily focused on integrating AI enhancements to boost .NET developer productivity”

    AI, beyond what already was in VS, is marginally beneficial to productivity. But MS is (and has been) ignoring the much larger productivity gains (and gains in developer “stickiness” to VS over other IDEs) that UI designers (functionally on par with the WinForms designer) for XAML (MAUI) and HTML/CSS (Blazor) would provide. After decades of the benefits of rapid application development with the WinForms UI designer, developers who benefitted from that are loathe to go back to the stone age of hand-coding UIs. And they laugh when some command line kiddie says, “Yeah, but ‘Hot Reload!'”.

    I can see MS growing VS Code to replace VS eventually for multiplatform development. Given the current aversion (and inability) of MS’s DevDiv to UI designers, my concern is that such designers will not make it (at least in their current highly productive state) to VS Code.

    1. Thanks for sharing your thoughts, Jeff. AI might not be perfect for everything, but it can definitely save hours on well-defined coding tasks. Plus, it’s still early days. I’m with you on the UI WYSIWYG designer.

  2. I believe all the .NET Core version are no longer in support. There is of course ASP.NET Core which is current. So, .NET 5,6,7, & 8 are multiplatform. MSFT would have to use one of these, but would loose support for the .NET Framework versions that support everything that made VS great. I doubt they would just bolt this functionality on the side of VS for Windows Developers. While MSFT embraces multi-platform development and open source, they are also a business that developed Windows, and would probably prefer you developed for it.

Leave a Reply

Your email address will not be published. Required fields are marked *