It is finished! PVS-Studio supports the analysis of projects for .NET 5
On November 10, 2020, a new version of .NET Core was released, officially named .NET 5. The updated platform provides many different capabilities. For example, it allows C # developers to use the innovations of C # 9: records, relational pattern matching, etc. Unfortunately, there are also disadvantages – it is impossible to correctly analyze such a project using PVS-Studio. Well … It was impossible before 🙂 After all, now this problem is in the past – the next release of PVS-Studio 7.13 will support the analysis of projects focused on .NET 5!
Aka .NET Core 4
.NET 5 is essentially a continuation of .NET Core 3.1. Changing the name to “.NET”, Microsoft decided to emphasize that this is the implementation that is now the main one and that it will be further developed. And after all, they did not deceive – on official website already at the time of this writing, it was possible to find as many as 3 preview-versions of .NET 6. However, why did the version following 3.1 become 5? Well, it doesn’t seem so surprising when you remember that Windows 10 comes after Windows 8.1 🙂
In fact, number 4 is omitted only to avoid confusion with the separation of .NET Framework and .NET. Despite this, “Entity Framework Core 5.0” based on .NET 5 will retain the “Core” postfix. This is because it would otherwise not be possible to distinguish between Core and Framework versions of “Entity Framework 5.0”.
.NET 5 brings many new features to developers. For example, C # has dramatically improved pattern matching. In addition, there is an unusual, but interesting opportunity to write code outside of functions and classes. Perhaps not every developer needs this, but surely this feature will also have its fans. A complete list of C # 9 innovations can be found at official website…
You can read about the general innovations of .NET 5 here…
PVS-Studio and .NET 5
Users often wrote to us asking us to support the analysis of .NET 5 projects. And we ourselves fully understood that it is extremely important to keep up with the times. However, support for new versions of the platform is an important, but far from the only vector of PVS-Studio development. In many ways, this is why I had to wait so long 🙁 But now we are finally ready to present you a new version that supports the analysis of projects for .NET 5.
New features will be available for versions of the analyzer for Windows, Linux and macOS. Windows versions, as before, require .NET Framework 4.7.2 installed. But to use the analyzer under Linux and macOS, .NET 5 is now required (previously .NET Core 3.1 was needed).
Why did the analyzer for Linux and macOS switch to .NET 5?
In general, initially we did not plan to transfer the analyzer for Linux / macOS from .NET Core 3.1 to .NET 5. No, of course, we were going to switch to a new version of the platform, but thought about doing it a little later. Well, the plans had to be changed as we faced a problem.
When analyzing projects focused on .NET Core (and, accordingly, .NET 5), PVS-Studio actively interacts with the SDK of the corresponding version. The difficulties arose due to the fact that the libraries from the .NET 5 SDK depend on “System.Runtime” version 5. At the same time, the analyzer focused on .NET Core 3.1 loads “System.Runtime” version 3.1 into memory. As a result, a conflict arose – the analyzer could not interact with the library from the SDK and the analysis did not go through.
Switching from .NET Core to .NET 5 completely solved this problem :).
Instant improvements
To implement project analysis support for .NET 5, we needed to update some dependencies. In particular, PVS-Studio now uses newer versions of Roslyn and MSBuild. This allows the analyzer to correctly parse code that uses the capabilities of C # 9. For example, earlier the analyzer could give false positives for code like
user = user with { Name = "Bill" }
The analyzer could not correctly process such a code, since it did not contain information about WithExpression… As a result, a warning was issued that the variable user assigned to itself. Of course, the same report also contained a warning that the analysis of this project was not supported. However, that doesn’t make it much easier :(. Fortunately, after the update, all such problems were solved by themselves. Other points we had to think about separately.
Problems with new versions
An evolving static analyzer is forced to adapt to new versions of the language. Obviously, when developing such a tool, it is impossible to take into account all the features that will appear in the language in the future. Support for the analysis of the new version of the language is not only about ensuring correct parsing and construction of semantics. It is equally important to review the existing code, evaluate the work of various internal technologies and diagnostic rules. Most likely, after the update, there will be a need to make some changes to the existing functionality.
One of the potentially problematic innovations I mentioned earlier – top-level statements… While working on the C # analyzer, in some cases we expected that local variable declarations, conditions, loops, etc. will always be inside methods. The appearance in the language of the possibility of writing C # code even without declaring a class … This is something interesting, of course, but for us it creates some difficulties. However, it is unlikely that all developers will suddenly start writing all the code outside of classes 🙂
Another innovation that made us change the code is init-accessor. Its appearance led to the need to refine the diagnostic rule. V3140…
The rule is triggered when different internal variables are used in property accessors. Below is an example of triggering from articles about RunUO validation:
private bool m_IsRewardItem;
[CommandProperty( AccessLevel.GameMaster )]
public bool IsRewardItem
{
get{ return m_IsRewardItem; }
set{ m_IsRewardItem = value; InvalidateProperties(); }
}
private bool m_East;
[CommandProperty( AccessLevel.GameMaster )]
public bool East // <=
{
get{ return m_East; }
set{ m_IsRewardItem = value; InvalidateProperties(); }
}
PVS-Studio warning: V3140 Property accessors use different backing fields. WallBanner.cs 77
When writing diagnostics V3140 it was assumed that a property can only have 2 accessors – get and set… The emergence init caught an existing implementation by surprise. Diagnostics didn’t just work incorrectly – it crashed with an exception! Fortunately, this problem was discovered during the testing phase and was successfully resolved.
Looking forward to the release?
And this is not necessary at all! Of course, the release is coming soon, so there is not long to wait, but still … I would like to try the new version as early as possible, right? Well, no problem – we will be happy to provide such an opportunity! Go to feedback page and send your request for a new version. We will try to answer as quickly as possible, which means that soon you will be able to analyze your (and not only) .NET 5 projects!
We also invite you to share your impressions of PVS-Studio. Whatever your experience of using the analyzer, we would like to know about it. Indeed, it is largely thanks to the feedback from users that PVS-Studio is developing and getting better.
If you want to share this article with an English-speaking audience, please use the translation link: Nikita Lipilin. Finally! PVS-Studio Supports .NET 5 Projects.
