Visual Studio 2022 is stylish and fresh. History of its support in PVS-Studio

It seems that the announcement of Visual Studio 2022 was only recently, and now it is already out. This meant exactly one thing – you need to support this IDE in the next release of PVS-Studio. About what difficulties we had to face, and what went without problems, we will talk today.

Impressions of the new IDE

To be honest, I really liked Visual Studio 2022. I just enjoy the new fonts, which have become less sharp or something. The colors have also become less acidic, and now it’s not so painful to put a breakpoint when debugging.

Below are a few examples for comparison. This is what the code snippet looks like in Visual Studio 2019:

This is what it looks like in Visual Studio 2022:

Important. Both images were taken at 100% scale.

Also, the dark theme has been corrected in the IDE – its combination with the purple color looks extremely harmonious (VS 2019 on the left, VS 2022 on the right):

In general, from an external point of view, the new VS looks holistic and fresh. Although I know that the Old Believers did not like it. 🙂

I also want to mention code completion. It does not interfere at all, and sometimes it really adds what I wanted to write:

Speaking of inconvenience, I’ve come across the fact that accepting autocompletion sometimes has to be done with the “right arrow” rather than tab. For some reason, in certain cases, instead of accepting autocompletion, the usual pressing of tab occurs. Perhaps this is not a very common problem – discussed with a colleague, he did not repeat. If you know how to fix this, please write in the comments. I want to note that since the first preview, there have been fewer such moments and, perhaps, it’s just a matter of time when everything will be corrected.

After working in this IDE and having fun, I decided that I wanted to take on the scheduled task about its support in order to quickly switch to a new version of VS. The fact is that after VS2022, VS2019 did not want to open at all. It seemed somewhat outdated (although the IDE itself is very useful). As they say, everything is known in comparison.

Plugin support

Here everything went smoothly. Changes we weren’t particularly bothered. So I just created a new plugin solution, updated the NuGet packages to the required versions, and did some other XML programming (such as editing .csproj files).

However, I had to correct the code a bit – the plugin solution for VS2022 was not built due to about 5 errors. All of them arose due to the fact that Microsoft slightly changed the API, but everything turned out to be not at all scary. For example, it was like this:

int Hwnd = DTE.MainWindow.HWnd;
return new NativeWindowWrapper(new IntPtr(Hwnd));

It became like this:

IntPtr Hwnd = DTE.MainWindow.HWnd;
return new NativeWindowWrapper(Hwnd);

The rest started out of the box. When everything came together, I decided to run the plugin to see how things were going. The buttons were pressed, the analysis started, the results were displayed. So we can assume that updating the plugin was easy. The next step was to update the toolsets. However, one curious moment suddenly surfaced, which I cannot but tell.

Most interesting moment

A non-obvious and interesting point that I encountered was related to solution-level file templates. These are the things that show up when we want to add a file to a solution:

This window opens, and all we see in it are templates:

As you can see, we have two templates of our own. Without going into details, one is needed for finer tuning of the analyzer, the other is for suppressing warnings. However, there was a problem with them. The templates themselves were easily added by analogy with the old plugins, but the picture was not:

What, how, why??? I didn’t have answers to these questions. So I had to dive deeper into how they are created.

These templates have their own format, and for those shown in the picture above, the code looks like this:

Filters.pvsconfig_template| |PVS-Studio Filters File|1|
PVS-Studio C#/C++ filters file can be used to filter,
 disable and modify C#/C++ analyzer messages on project and 
solution.|{installDir}PVSLoader.exe|#32512| |Filters.pvsconfig

SuppressionFile.suppress_template| |PVS-Studio Suppress File|2|
An empty PVS-Studio suppression file. You can suppress analyzer messages 
in your code from 'PVS-Studio >Suppress Messages...' menu item. 
Only one suppression file per solution is allowed. 
Other files will be ignored.|{installDir}PVSLoader.exe|#32512
| |SuppressionFile.suppress

Each position between | responsible for certain content. If there is a space, then there will be no content. The content of the template itself is set separately.

Let’s see what the description format is:

  1. the name of the folder, template, or .vsz file, such as HeaderFile.h or MyWizard.vsz;

  2. GUID of the VSPackage;

  3. template name;

  4. the relative display order of the template;

  5. description;

  6. the path to the executable file, from where you need to take the picture;

  7. picture ID;

  8. a field used to disable or enable the “Name” and “Location” fields in the “Add New Item” dialog box;

  9. the name of the file created from the template.

You can read more about this format here. here.

Since we do not have a picture, the suspicion falls on points 6 and 7. At first, I decided to read how to calculate the ID of a picture in an executable file and something became discouraged. 🙁 In these Internets of yours, they said that you need to download a special program. At the same time, all links to such programs looked, let’s say, not very official. I didn’t want to resort to this method right away, so I decided to look at the IL code using IL DASM. I didn’t find anything there either. There was no mention of the number 32512. I decided, maybe this number is written in a different number system, I tried to convert and search, but again by. Phew…

And then my brain is like this: “Let’s just try another .exe slip.” Yeah why not? I take and transfer another file, and, lo and behold, it works! As it turned out in the end, it’s all about the bit depth of the transferred file. All Visual Studios prior to 2022 were 32-bit, and they needed a picture app to match. 2022 has become 64-bit. This is such a funny problem.

New toolset support

To better understand what’s going on, I highly recommend reading the relevant sections of the Visual Studio support articles. 2017 and 2019.

Unlike the plugin support, which went pretty smoothly, the toolset support turned out to be quite an adventure. Now I will explain what the main problem is. Look, we have the MSBuild.exe.config file, in which we set the various properties necessary for evaluation (building a project model). Before VS2022 support, it looked something like this:

<?xml version="1.0" encoding="utf-8"?>
 <msbuildToolsets default="Current">
  <toolset toolsVersion="Current">
   <property name="VsInstallRoot" value="$(PVSBuildTools_InstallDir_VS2019)" />
   <property name="MSBuildToolsRoot" value="$(VsInstallRoot)MSBuild" />
   <property name="VCTargetsPath" 
                   '$(MSBuildExtensionsPath32)MicrosoftVCv160'))" />

  <toolset toolsVersion="15.0">
   <property name="VsInstallRoot" value="$(PVSBuildTools_InstallDir_VS2017)" />
   <property name="MSBuildToolsRoot" value="$(VsInstallRoot)MSBuild" />
   <property name="VCTargetsPath"
                   '$(VsInstallRoot)Common7IDEVCVCTargets'))" />

This is only a snippet of the file, but it’s enough to show the point. As you can see, there are 2 toolsets here: ‘Current’ for VS2019 and 15.0 for VS2017. Now Microsoft is releasing VS2022 and the naming picture is starting to look like this:

Note that the Tools Version names for VS2019 and VS2022 are the same. And that’s a problem, because you can’t give two different toolsets the same name. Therefore, we decided that instead of the name, we will dynamically change the content. We leave ‘Current’, to initialize toolsets, as before, we use environment variables. The values ​​for these variables are calculated based on the versions of Visual Studio installed on the system, or which version of VS we are currently running.

As a result, we have one ‘Current’ toolset that can work with both VS2019 and VS2022, and in the future – with new versions of the IDE. Here is a diagram that illustrates this process:

Once again, it is worth emphasizing that the situation when the environment variable is set is taken into account separately VisualStudioVersion with a value of 16.0 or 17.0. In this case, we calculate and use for ‘Current’ the value of the specified VS.

Thus, we managed to solve the current problem with the same name of different toolsets, and also make the mechanism universal and easily extensible (I want to believe) for new VS.

.NET 6 support, Roslyn and MSBuild library updates

Since VS2022 and .NET 6 were released together, PVS-Studio also needed to add support for both within the same release. As a result, we simultaneously supported Visual Studio 2022 and analysis of projects under .NET 6, work with the .NET 6 SDK, updated the MSBuild and Roslyn libraries.

As usual, with the support of the new version of .NET, a lot of specifics came out related to the fact that we use our own BuildTools. By the way, you can read about what we encountered with .NET 5 support. here.

Synchronization of our BuildTools and BuildTools .NET

Why this is needed and how it is implemented is described in articles about support. VS2017 and VS2019. It may seem that own BuildTools is an extra headache. However, as practice has shown, this approach gives greater stability / flexibility.

Besides, this is a good opportunity to tinker with .targets / .props files and start to better understand the relevant part of PVS-Studio and the .NET ecosystem in general.

Debugging Roslyn and MSBuild

When working with Roslyn / MSBuild, sometimes some non-obvious problems pop up (for example, the project loses some of the links), because of which you have to dive into the sources. In our project, we even have a special configuration for debugging Roslyn and MSBuild built from source. 🙂

The fact that these (and many others) projects from Microsoft are open source is very helpful. If you need to find out something, you can debug the code and see how and what works.

It can be difficult at first, but over time, you get pretty good at navigating those parts of these projects that you have to come back to from time to time. When you find yourself in those places in the code where you have not been for several years, it feels a bit like returning home.

I repeat what I said above – working with such tasks gives a better understanding of how the compiler / build system works.

Moving to .NET 6 and C# 10 support

The PVS-Studio analyzer for C# for Linux and macOS now works under .NET 6. In addition, when updating Roslyn, we got support for C# 10 out of the box. Yes, improvements to diagnostics, data-flow, etc. you will have to do it yourself, but the correct analysis of the new syntax and understanding of the semantics is also great. Updating the MSBuild libraries gives, accordingly, out-of-the-box support for new features of this build system.

So, if you suddenly missed this event, now you have the opportunity to analyze your projects under .NET 6. 😉


Once again, I want to emphasize that the new Visual Studio, in my opinion, is very good. Microsoft clearly did their best. The update of the plugin itself for it went smoothly, and this is good news. The toolset update allowed us to look into those things that fate may not bring.

After a month, we can say that Visual Studio 2022 was successfully supported, backward compatibility was not broken and received positive feedback. Special thanks to all those who were interested in the plugin for this IDE and managed to test the beta version.

So if you wanted try a bunch of PVS-Studio and Visual Studio 2022, but somehow the hands didn’t reach – now is the time.

If you want to share this article with an English-speaking audience, please use the translation link: Nikolay Mironov. Visual Studio 2022 – stylish and fresh. How PVS-Studio supported VS2022.

Similar Posts

Leave a Reply