April 22, 2024 7 minutes read
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
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.
Index
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) :
Native Calls in the Visual Studio Code Base
With this C# LINQ code query we obtain 9.769 native methods (Platform Invoke):
1 | from m in Methods where m.IsPInvokeImpl select m |
It is interesting to look at the distribution of native calls in Visual Studio DLLs with this query:
C
1 2 3 4 5 6 7 | let pInvokeImpls = Methods.Where(m => m.IsPInvokeImpl).ToHashSetEx() let asm = pInvokeImpls.ParentAssemblies() from a in asm let calls = a.ChildMethods.Intersect(pInvokeImpls).ToArray() orderby calls.Length descending select new { a, calls} |
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 Usage of WPF and Winforms
Let’s query the Visual Studio classes and structures that are using WPF or Winforms:
1 2 3 4 5 6 7 | let uiTypes = ThirdParty.Assemblies.WithNameIn( "PresentationFramework", "PresentationCore", "System.Windows.Form", "System.Drawing").ChildTypes().ToHashSetEx() from t in Application.Types.UsingAny(uiTypes) select new { t, uiTypesUsed = t.TypesUsed.Intersect(uiTypes) } |
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.
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.
C
1 2 3 4 | from a in Application.Assemblies where a.TargetFrameworkName.StartsWithAny("net4", "net20", "net10") orderby a.NbILInstructions descending select new { a, a.TargetFrameworkName, a.ChildTypes, a.NbILInstructions } |
Here are the results:
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.
.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.
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.
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.
