{"id":29368,"date":"2020-08-27T11:00:02","date_gmt":"2020-08-27T18:00:02","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/dotnet\/?p=29368"},"modified":"2021-09-29T12:15:49","modified_gmt":"2021-09-29T19:15:49","slug":"automatically-find-latent-bugs-in-your-code-with-net-5","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/automatically-find-latent-bugs-in-your-code-with-net-5\/","title":{"rendered":"Automatically find latent bugs in your code with .NET 5"},"content":{"rendered":"
\n

It’s an exciting time to be writing code! Especially for .NET developers as the platform keeps getting smarter. We now include rich diagnostics and code suggestions in the .NET SDK by default. Before you would need to install NuGet packages or other stand-alone tools to get more code analysis. Now, you will automatically get these in the new .NET 5 SDK.<\/p>\n

In the past, we’ve been reluctant to add new warnings to C#. This is because adding new warnings is technically a source breaking change for users who have warnings set as errors. However, there are a lot of cases we’ve come across over the years where we also really want to warn people that something was wrong, ranging from common coding mistakes to common API misuse patterns.<\/p>\n

Starting with .NET 5, we’re introducing what we’re calling AnalysisLevel<\/code> in the C# compiler to introduce warnings for these patterns in a safe way. The default Analysis Level for all projects targeting .NET 5 will be set to 5, meaning that more warnings (and suggestions to fix them) will be introduced.<\/p>\n

Let’s talk about what the possible values for AnalysisLevel<\/code> mean in your project. First thing we should note: unless you override the default, AnalysisLevel<\/code> is set based on your target framework:<\/p>\n

<\/div>\n<\/div>\n\n\n\n\n\n\n\n
Target Framework<\/td>\nDefault for AnalysisLevel<\/code><\/td>\n<\/tr>\n
net5.0<\/code><\/td>\n5<\/td>\n<\/tr>\n
netcoreapp3.1<\/code>\u00a0or lower<\/td>\n4<\/td>\n<\/tr>\n
netstandard2.1<\/code>\u00a0or lower<\/td>\n4<\/td>\n<\/tr>\n
.NET Framework 4.8<\/code>\u00a0or lower<\/td>\n4<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

 <\/p>\n

However, what about the numbers 0-3? here is a more detailed breakdown of what each analysis level value means.<\/p>\n\n\n\n\n\n\n\n\n\n
AnalysisLevel<\/code><\/td>\nEffect On C# Compiler<\/td>\nAdvanced Platform API Analysis<\/td>\n<\/tr>\n
5<\/td>\nGet new compiler language analysis (details below)<\/td>\nYes<\/td>\n<\/tr>\n
4<\/td>\nidentical to passing\u00a0-warn:4<\/code>\u00a0to the C# compiler in previous versions<\/td>\nNo<\/td>\n<\/tr>\n
3<\/td>\nidentical to passing\u00a0-warn:3<\/code>\u00a0to the C# compiler in previous versions<\/td>\nNo<\/td>\n<\/tr>\n
2<\/td>\nidentical to passing\u00a0-warn:2<\/code>\u00a0to the C# compiler in previous versions<\/td>\nNo<\/td>\n<\/tr>\n
1<\/td>\nidentical to passing\u00a0-warn:1<\/code>\u00a0to the C# compiler in previous versions<\/td>\nNo<\/td>\n<\/tr>\n
0<\/td>\nidentical to passing\u00a0-warn:0<\/code>\u00a0to the C# compiler in previous versions, turns off all emission of warnings<\/td>\nNo<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

 <\/p>\n

Since AnalysisLevel<\/code> is tied to the target framework of your project, unless you change what your code targets, you will never change your default analysis level. You can manually set your analysis level though. For example, even if we are targeting .NET Core App 3.1 or .NET Standard (and therefore have AnalysisLevel<\/code> defaulted to 4) you can still opt into a higher level.<\/p>\n

Here is an example of doing that:<\/p>\n

<Project\u00a0Sdk=\"Microsoft.NET.Sdk\">\r\n\r\n\u00a0\u00a0<PropertyGroup>\r\n\u00a0\u00a0\u00a0\u00a0<OutputType>Exe<\/OutputType>\r\n\u00a0\u00a0\u00a0\u00a0<TargetFramework>netcoreapp3.1<\/TargetFramework>\r\n\u00a0\u00a0\u00a0\u00a0<!--\u00a0get\u00a0more\u00a0advanced\u00a0warnings\u00a0for\u00a0this\u00a0project\u00a0-->\r\n\u00a0\u00a0\u00a0\u00a0<AnalysisLevel>5<\/AnalysisLevel>\r\n\u00a0\u00a0<\/PropertyGroup>\r\n\r\n<\/Project><\/pre>\n
\n
If you always want to be on the highest supported analysis level you can specify latest<\/code> in your project file:<\/span><\/div>\n<\/div>\n
<Project Sdk=\"Microsoft.NET.Sdk\">\r\n\r\n  <PropertyGroup>\r\n    <OutputType>Exe<\/OutputType>\r\n    <TargetFramework>netcoreapp3.1<\/TargetFramework>\r\n    <!-- be automatically updated to the newest stable level -->\r\n    <AnalysisLevel>latest<\/AnalysisLevel>\r\n  <\/PropertyGroup>\r\n\r\n<\/Project><\/pre>\n
If you are\u00a0very\u00a0<\/em>adventurous and want to try out experimental compiler and platform analysis you can specify\u00a0preview\u00a0<\/code>to get the latest, cutting-edge code diagnostics.<\/p>\n
Please note that when<\/span> you use latest<\/code> or<\/span> preview<\/code>, the analysis results might vary between machines, depending on the available SDK and<\/span> the highest analysis level it offers.<\/p>\n
<Project Sdk=\"Microsoft.NET.Sdk\">\r\n\r\n  <PropertyGroup>\r\n    <OutputType>Exe<\/OutputType>\r\n    <TargetFramework>netcoreapp3.1<\/TargetFramework>\r\n    <!-- be opted into experimental code correctness warnings -->\r\n    <AnalysisLevel>preview<\/AnalysisLevel>\r\n  <\/PropertyGroup>\r\n\r\n<\/Project><\/pre>\n
Finally, we have\u00a0none\u00a0<\/code>which means\u00a0“I don’t want to see any new warnings.”<\/em> In this mode, you won’t get any of the <\/span>advanced API <\/span>analysis nor new compiler warnings.<\/span> This is useful <\/span>if<\/span> you need to update your framework but you’re <\/span>not<\/span> ready to absorb new warnings yet.<\/span><\/p>\n
<Project Sdk=\"Microsoft.NET.Sdk\">\r\n\r\n  <PropertyGroup>\r\n    <OutputType>Exe<\/OutputType>\r\n    <TargetFramework>net5.0<\/TargetFramework>\r\n    <!-- I am just fine thanks -->\r\n    <AnalysisLevel>none<\/AnalysisLevel>\r\n  <\/PropertyGroup>\r\n\r\n<\/Project><\/pre>\n
You can also configure the analysis level for a project from within Visual Studio via the Code Analysis property page. Just navigate to the project property page from the Solution Explorer. Then go to the Code Analysis tab.<\/p>\n
\"Configure<\/p>\n
In the future we will add a new analysis level for every release of .NET. The goal is to make sure that a given analysis level always represents the same set of analysis defaults (the rules and<\/span> their severities). If<\/span> we want to turn an existing rule on by default, we’ll do<\/span> this in an upcoming analysis level, instead of changing the existing level. This ensures that a given project\/source always produces the same warning, regardless of how new the SDK is (unless<\/span> the project uses preview<\/code> or<\/span> latest<\/code>, of course).<\/p>\n
Since all .NET 5 projects will be opted into <\/span>Analysis Level 5<\/em>, let’s look at some of the new warnings and suggestions that will be offered.<\/span><\/p>\n
 <\/p>\n
All New Warnings and Errors coming in Analysis Level 5<\/h2>\n
The ones in\u00a0bold<\/strong>\u00a0are going to be in level 5 by the time .NET 5 ships. The rest are new warnings are available\u00a0today\u00a0in .NET 5 Preview 8 with Visual Studio 2019 16.8 Preview 2!<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Id<\/td>\nCategory<\/td>\nSeverity<\/td>\nDescription<\/td>\n<\/tr>\n
CA1416<\/strong><\/strong><\/a><\/td>\nInteroperability<\/strong><\/td>\nWarning<\/strong><\/td>\nWarn when code does not work across all platforms<\/strong><\/td>\n<\/tr>\n
CA1417<\/a><\/td>\nInteroperability<\/td>\nWarning<\/td>\nDo not use OutAttribute<\/code> on string parameters for P\/Invokes<\/td>\n<\/tr>\n
CA1831<\/a><\/td>\nPerformance<\/td>\nWarning<\/td>\nUse AsSpan<\/code> instead of Range-based indexers for string when appropriate<\/td>\n<\/tr>\n
CA2013<\/a><\/td>\nReliability<\/td>\nWarning<\/td>\nDo not use ReferenceEquals<\/code> with value types<\/td>\n<\/tr>\n
CA2014<\/a><\/td>\nReliability<\/td>\nWarning<\/td>\nDo not use\u00a0stackalloc\u00a0<\/code>in loops<\/td>\n<\/tr>\n
CA2015<\/a><\/td>\nReliability<\/td>\nWarning<\/td>\nDo not define finalizers for types derived from\u00a0MemoryManager<\/code><\/td>\n<\/tr>\n
CA2200<\/strong><\/strong><\/a><\/td>\nUsage<\/strong><\/td>\nWarning<\/strong><\/td>\nRethrow to preserve stack details<\/strong><\/td>\n<\/tr>\n
CA2247<\/a><\/td>\nUsage<\/td>\nWarning<\/td>\nArgument passed to\u00a0TaskCompletionSource<\/code>\u00a0calls the wrong constructor<\/td>\n<\/tr>\n
CS0177<\/a><\/td>\nCorrectness<\/td>\nWarning<\/td>\ntrack definite assignment of structs across assemblies<\/td>\n<\/tr>\n
CS0185<\/strong><\/strong><\/a><\/td>\nCorrectness<\/strong><\/td>\nError<\/strong><\/td>\ndo not allow locks on non-reference types<\/strong><\/td>\n<\/tr>\n
CS7023<\/strong><\/strong><\/a><\/td>\nCorrectness<\/strong><\/td>\nError<\/strong><\/td>\ndo not allow\u00a0as\u00a0<\/code>or\u00a0is<\/code>\u00a0on static types<\/strong><\/td>\n<\/tr>\n
CS8073<\/a><\/td>\nUsage<\/td>\nWarning<\/td>\nwarn when expression is always false or true<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
 <\/p>\n
Warnings for common mistakes<\/h2>\n
The first set of new warnings are intended to find latent bugs, often in larger codebases. These can be very easy to introduce without additional compiler analysis today.<\/p>\n
Warn when expression is always true or false<\/h3>\n
This new warning is extremely common. Consider the following code:<\/p>\n
public void M(DateTime dateTime)\r\n{\r\n    if (dateTime == null) \/\/ warning CS8073\r\n    {\r\n        return;\r\n    }\r\n}<\/pre>\n
DateTime<\/code> is a struct<\/code> and struct<\/code>s cannot be null<\/code>. Starting in .NET 5 we will warn about this case with CS8073<\/code>. The warning message is:<\/p>\n
Warning CS8073: The result of the expression is always ‘false’ since the value of type ‘DateTime’ is never equal to ‘null’ of type ‘DateTime?’<\/em><\/p>\n
It might seem rather obvious what this code is doing is unnecessary in isolation but consider that such a check might occur in a method with 10 parameters to validate. To fix this you can remove the code (since its always false it’s not doing anything anyways), or change its type to DateTime?<\/code> if null<\/code> is an intended value for the parameter.<\/p>\n
public void M(DateTime? dateTime) \/\/ We accept a null DateTime\r\n{\r\n    if (dateTime == null) \/\/ No Warnings\r\n    {\r\n        return;\r\n    }\r\n}<\/pre>\n
 <\/p>\n
Do not allow as or is on static types<\/h3>\n
This next one is a nice little enhancement:<\/p>\n
static class Fiz\r\n{\r\n}\r\n\r\nclass P\r\n{\r\n    bool M(object o)\r\n    {\r\n        return o is Fiz; \/\/ CS7023\r\n    }\r\n}<\/pre>\n
Because Fiz\u00a0<\/code>is a static class an instance object like\u00a0o<\/code>\u00a0will never be able to be an instance of this type. We will get this warning:<\/p>\n
Warning CS7023 The second operand of an ‘is’ or ‘as’ operator may not be static type ‘Fiz’<\/em><\/p>\n
The fix for this is to refactor our code (maybe we are actually checking against the wrong type to begin with), or to make the class\u00a0Fiz\u00a0<\/code>non-static:<\/p>\n
class Fiz\r\n{\r\n}\r\n\r\nclass P\r\n{\r\n    bool M(object o)\r\n    {\r\n        return o is Fiz; \/\/ no error\r\n    }\r\n}<\/pre>\n
 <\/p>\n
Do not allow locks on non-reference types<\/h3>\n
locking on a non-reference type (like an\u00a0int<\/code>) does nothing because they are pass-by-value so a different version of them lives on every stack frame. In the past we would warn you about locking on non-reference types for simple cases like\u00a0lock(5)<\/code>\u00a0but until recently we would not warn you for open generics like below.<\/p>\n
public class P\r\n{\r\n    public static void GetValue<TKey>(TKey key)\r\n    {\r\n        lock (key) \/\/ CS0185\r\n        {\r\n        }\r\n    }\r\n\r\n    static void Main()\r\n    {\r\n        GetValue(1);\r\n    }\r\n}<\/pre>\n
This is an error because passing in an int (which is allowed under this unconstrained generic) will not actually lock correctly. We’ll see this error:<\/p>\n
Error\u00a0CS0185\u00a0‘TKey’\u00a0is\u00a0not\u00a0a\u00a0reference\u00a0type\u00a0as\u00a0required\u00a0by\u00a0the\u00a0lock\u00a0statement<\/em><\/p>\n
To fix this we need to indicate that the\u00a0GetValue\u00a0<\/code>method should only be given reference types. We can do this with the generic type constraint\u00a0where TKey : class<\/code><\/p>\n
public class P\r\n{\r\n    public static void GetValue<TKey>(TKey key) where TKey : class\r\n    {\r\n        lock (key) \/\/ no error\r\n        {\r\n        }\r\n    }\r\n}<\/pre>\n
 <\/p>\n
Rethrow to preserve stack details<\/h3>\n
We’re all good (?) developers so our code never throws exceptions, right? Well even the best developers need to handle exceptions in .NET and one of the common pitfalls new programmers fall into is this:<\/p>\n
try\r\n{\r\n    throw new Exception();\r\n}\r\ncatch (Exception ex)\r\n{\r\n    \/\/ probably logging some info here...\r\n\r\n    \/\/ rethrow now that we are done\r\n    throw ex; \/\/ CA2200\r\n}<\/pre>\n
In school I learned that if someone threw the ball at me and I caught it, I had to throw the ball back! Metaphors like this lead lots of folks to believe that\u00a0throw ex<\/code>\u00a0is the correct way to re-throw this exception. Sadly, this will change the stacks in the original exception. Now you will get a warning that this is happening. It looks like this:<\/p>\n
Warning\u00a0CA2200\u00a0Re-throwing\u00a0caught\u00a0exception\u00a0changes\u00a0stack\u00a0information<\/em><\/p>\n
In nearly all cases the correct thing to do here is to simply use the\u00a0throw\u00a0<\/code>keyword without mentioning the variable of the exception we caught.<\/p>\n
try\r\n{\r\n    throw new Exception();\r\n}\r\ncatch (Exception ex)\r\n{\r\n    \/\/ probably logging some info here...\r\n\r\n    \/\/ rethrow now that we are done\r\n    throw;\r\n}<\/pre>\n
We also offer a code fix to easily fix up all of these at once in your document, project, or solution!<\/p>\n
\"Code<\/p>\n
 <\/p>\n
Do not use ReferenceEquals with value types<\/h3>\n
Equality is a tricky topic in .NET. This next warning strives to make accidentally comparing a struct\u00a0<\/code>by reference apparent. Consider the code below:<\/p>\n
int int1 = 1;\r\nint int2 = 1;\r\nConsole.WriteLine(object.ReferenceEquals(int1, int2)); \/\/ warning CA2013<\/pre>\n
This will box the two int<\/code>s and\u00a0ReferenceEquals\u00a0<\/code>will always return false as a result. We will see this warning description:<\/p>\n
Warning CA2013: Do not pass an argument with value type ‘int’ to ‘ReferenceEquals’. Due to value boxing, this call to ‘ReferenceEquals’ will always return ‘false’.<\/em><\/p>\n
The fix for this error is to either use the equality operator\u00a0==<\/code>\u00a0or\u00a0object.Equals<\/code>\u00a0like so:<\/p>\n
int int1 = 1;\r\nint int2 = 1;\r\nConsole.WriteLine(int1 == int2); \/\/ using the equality operator is fine\r\nConsole.WriteLine(object.Equals(int1, int2));  \/\/ so is object.Equals<\/pre>\n
 <\/p>\n
Track definite assignment of structs across assemblies<\/h3>\n
This next warning is something that a lot of people may be surprised to learn wasn’t already a warning:<\/p>\n
using System.Collections.Immutable;\r\n\r\nclass P\r\n{\r\n    public void M(out ImmutableArray<int> immutableArray) \/\/ CS0177\r\n    {\r\n    }\r\n}<\/pre>\n
This rule is all about definite assignment<\/a>,\u00a0a useful feature in C# that makes sure you don’t forget to assign values to your variables.<\/p>\n
Warning CS0177: The out parameter ‘immutableArray’ must be assigned to before control leaves the current method<\/em><\/p>\n
CS0177\u00a0<\/code>is already issued for several different situations today, but not in the case previously shown. The history here is that this was a bug that traces itself all the way back to the original implementations of the C# compiler. Previously, the C# compiler ignored private fields of reference types in a value type imported from metadata when computing definite assignment. This extremely <\/i>specific\u00a0bug meant that a type like\u00a0ImmutableArray\u00a0<\/code>was able to escape definite assignment analysis. Ouch!<\/p>\n
Now the compiler will correctly error for you and you can fix it by simply ensuring that it is always assigned a value, like so:<\/p>\n
using System.Collections.Immutable;\r\n\r\nclass P\r\n{\r\n    public bool M(out ImmutableArray<int> immutableArray) \/\/ no warning\r\n    {\r\n        immutableArray = ImmutableArray<int>.Empty;\r\n    }\r\n}<\/pre>\n
 <\/p>\n
Warning for incorrect .NET API usage<\/h2>\n
The next examples are about correctly using .NET libraries. Analysis Levels allow for guarding against improper use of existing .NET APIs today, but it also has an impact on .NET library evolution moving forward. If a useful API is designed but it has the potential for misuse, a new warning that detects misuse can also be added in tandem with the new API.<\/p>\n
 <\/p>\n
Do not define finalizers for types derived from MemoryManager<\/h3>\n
MemoryManager<\/code> is a useful class for when you want to implement your own Memory<T><\/code> type. This is not something you’re likely to find yourself doing a lot, but when you need it you really <\/em>need it. This new warning triggers for cases like this:<\/p>\n
class DerivedClass <T> : MemoryManager<T>\r\n{\r\n    public override bool Dispose(bool disposing)\r\n    {\r\n        if (disposing)\r\n        {\r\n            _handle.Dispose();\r\n        }\r\n    }\r\n  \r\n    ~DerivedClass() => Dispose(false); \/\/ warning CA2015\r\n}<\/pre>\n
Adding a finalizer to this type can introduce holes in the garbage collector, which we all would prefer to avoid!<\/p>\n
Warning CA2015 Adding a finalizer to a type derived from MemoryManager<T> may permit memory to be freed while it is still in use by a Span<T>.<\/em><\/p>\n
The fix is to remove this finalizer, since it will cause very subtle bugs in your program that will be hard to find and fix.<\/p>\n
class DerivedClass <T> : MemoryManager<T>\r\n{\r\n    public override bool Dispose(bool disposing)\r\n    {\r\n        if (disposing)\r\n        {\r\n            _handle.Dispose();\r\n        }\r\n    }\r\n \/\/ No warning, since there is no finalizer here\r\n}<\/pre>\n
 <\/p>\n
Argument passed to TaskCompletionSource calls the wrong constructor<\/h3>\n
This warning notifies us that we’ve used just\u00a0slightly\u00a0the wrong enum.<\/p>\n
var\u00a0tcs\u00a0=\u00a0new\u00a0TaskCompletionSource(TaskContinuationOptions.RunContinuationsAsynchronously);\u00a0\/\/\u00a0warning\u00a0CA2247<\/pre>\n
Unless you are already aware of the issue you may stare at this for a bit before you see it. The problem is that this constructor does not take a\u00a0TaskContinuationOptions\u00a0<\/code>enum it takes a\u00a0TaskCreationOptions\u00a0<\/code>enum. What is happening is that we are calling the constructor for\u00a0TaskCompletionSource\u00a0<\/code>that accepts\u00a0object<\/code>! Considering how similar their names are and that they have very similar values this mistake is easy to make.<\/p>\n
Warning\u00a0CA2247:\u00a0Argument\u00a0contains\u00a0TaskContinuationsOptions\u00a0enum\u00a0instead\u00a0of TaskCreationOptions\u00a0enum.<\/em><\/p>\n
The fix is to pass in the correct enum type:<\/p>\n
var\u00a0tcs\u00a0=\u00a0new\u00a0TaskCompletionSource(TaskCreationOptions.RunContinuationsAsynchronously);\u00a0\/\/\u00a0no\u00a0warning<\/pre>\n
 <\/p>\n
Warn when code does not work across all platforms<\/h3>\n
This last one is a doozy! I won’t go into all its intricacies here (look forward to a future blog post on that topic). But the purpose of warnings here is to let you know that the APIs you are calling may not work on all the targets you are building for.<\/p>\n
Let’s say I have an app that runs on both Linux and Windows. I have a method that I use to get the path to create log files under and it has different behavior based on where it is running.<\/p>\n
private static string GetLoggingPath()\r\n{\r\n    var appDataDirectory = Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData);\r\n    var loggingDirectory = Path.Combine(appDataDirectory, \"Fabrikam\", \"AssetManagement\", \"Logging\");\r\n\r\n    \/\/ Create the directory and restrict access using Windows\r\n    \/\/ Access Control Lists (ACLs).\r\n\r\n    var rules = new DirectorySecurity(); \/\/ CA1416\r\n    rules.AddAccessRule(\r\n        new FileSystemAccessRule(@\"fabrikam\\log-readers\",\r\n                                    FileSystemRights.Read,\r\n                                    AccessControlType.Allow)\r\n    );\r\n    rules.AddAccessRule(\r\n        new FileSystemAccessRule(@\"fabrikam\\log-writers\",\r\n                                    FileSystemRights.FullControl,\r\n                                    AccessControlType.Allow)\r\n    );\r\n\r\n    if (!OperatingSystem.IsWindows())\r\n    {\r\n        \/\/ Just create the directory\r\n        Directory.CreateDirectory(loggingDirectory);\r\n    }\r\n    else\r\n    {\r\n        Directory.CreateDirectory(loggingDirectory, rules);\r\n    }\r\n\r\n    return loggingDirectory;\r\n}<\/pre>\n
I correctly use the\u00a0OperatingSystem<\/a> helper to check if the OS is windows with OperatingSystem.IsWindows()<\/code> and only pass the rules for that case, but I actually have already used platform specific APIs that will not work on Linux!<\/p>\n
Warning\u00a0CA1416:\u00a0‘DirectorySecurity’\u00a0is\u00a0unsupported\u00a0on\u00a0‘Linux’<\/em><\/p>\n
The correct way to handle this is to move all my platform specific code inside the\u00a0else\u00a0statement.<\/p>\n
private static string GetLoggingPath()\r\n{\r\n    var appDataDirectory = Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData);\r\n    var loggingDirectory = Path.Combine(appDataDirectory, \"Fabrikam\", \"AssetManagement\", \"Logging\");\r\n\r\n    if (!OperatingSystem.IsWindows())\r\n    {\r\n        \/\/ Just create the directory\r\n        Directory.CreateDirectory(loggingDirectory);\r\n    }\r\n    else\r\n    {\r\n        \/\/ Create the directory and restrict access using Windows\r\n        \/\/ Access Control Lists (ACLs).\r\n\r\n        var rules = new DirectorySecurity(); \/\/ no warning\r\n        rules.AddAccessRule(\r\n            new FileSystemAccessRule(@\"fabrikam\\log-readers\",\r\n                                        FileSystemRights.Read,\r\n                                        AccessControlType.Allow)\r\n        );\r\n        rules.AddAccessRule(\r\n            new FileSystemAccessRule(@\"fabrikam\\log-writers\",\r\n                                        FileSystemRights.FullControl,\r\n                                        AccessControlType.Allow)\r\n        );\r\n\r\n        Directory.CreateDirectory(loggingDirectory, rules);\r\n    }\r\n\r\n    return loggingDirectory;\r\n}<\/pre>\n
 <\/p>\n
Low level coding help<\/h2>\n
There are also a few warnings that are useful when writing high-performance applications. These next set of warnings ensure you don\u2019t need to sacrifice safety for these cases.<\/p>\n
 <\/p>\n
Do not use OutAttribute on string parameters for P\/Invokes<\/h3>\n
Sometimes you need to interoperate with native code. .NET has the concept of platform invocations\u00a0(P\/Invokes<\/a>) to make this process easier. However, there are a few gotchas in terms of sending data to and from native libraries in .NET. Consider the code below:<\/p>\n
[DllImport(\"MyLibrary\")]\r\nprivate static extern void Goo([Out] string s); \/\/ warning CA1417<\/pre>\n
Unless you are very familiar with writing P\/Invokes, it’s not obvious what is wrong here. You normally apply\u00a0OutAttribute\u00a0<\/code>to types that the runtime doesn’t know about to indicate how the type should be marshaled. The OutAttribute implies that you are passing the data by value. It doesn’t make sense for strings to be passed by value though and has the potential to crash the runtime.<\/p>\n
Warning CA1417 Do not use the ‘OutAttribute’ for string parameter ‘s’ which is passed by value. If marshalling of modified data back to the caller is required, use the ‘out’ keyword to pass the string by reference instead.<\/em><\/p>\n
The fix for this is to either treat it as a normal out parameter (passing by reference).<\/p>\n
[DllImport(\"MyLibrary\")]\r\nprivate static extern void Goo(out string s); \/\/ no warning<\/pre>\n
or if you don\u2019t need the string marshaled back to the caller you can just do this:<\/p>\n
[DllImport(\"MyLibrary\")]\r\nprivate static extern void Goo(string s); \/\/ no warning<\/pre>\n
 <\/p>\n
Use AsSpan instead of Range-based indexers for string when appropriate<\/h3>\n
This is all about making sure that you don\u2019t accidentally allocate a string.<\/p>\n
class Program\r\n{\r\n    public void TestMethod(string str)\r\n    {\r\n        ReadOnlySpan<char> slice = str[1..3]; \/\/ CA1831\r\n    }\r\n}<\/pre>\n
In the code above its clear the developers intent is to index a string using the new range-based index<\/a> feature in C#. Unfortunately, this will actually allocate a string unless you convert that string to a span first.<\/p>\n
Warning CA1831 Use ‘AsSpan’ instead of the ‘System.Range’-based indexer on ‘string’ to avoid creating unnecessary data copies<\/em><\/p>\n
The fix is to just add AsSpan calls in this case:<\/p>\n
class Program\r\n{\r\n    public void TestMethod(string str)\r\n    {\r\n        ReadOnlySpan<char> slice = str.AsSpan()[1..3]; \/\/ no warning\r\n    }\r\n}<\/pre>\n
Do not use stackalloc in loops<\/h3>\n
The stackalloc<\/a> <\/code>keyword is great for when you want to make sure the operations you are doing are easy on the garbage collector. In the past,\u00a0stackalloc\u00a0<\/code>was only allowed in unsafe code, but since C# 8 it’s also been allowed outside of\u00a0unsafe<\/code> blocks so long as that variable is assigned to a Span<T><\/code> or a ReadOnlySpan<T><\/code>.<\/p>\n
class C\r\n{\r\n    public void TestMethod(string str)\r\n    {\r\n        int length = 3;\r\n        for (int i = 0; i < length; i++)\r\n        {\r\n            Span<int> numbers = stackalloc int[length]; \/\/ CA2014\r\n            numbers[i] = i;\r\n        }\r\n    }\r\n}<\/pre>\n
Allocating a lot on the stack can lead to the famous StackOverflow exception, where we’ve allocated more memory on the stack than allowed. Allocating in a loop is especially perilous.<\/p>\n
Warning CA2014 Potential stack overflow. Move the stackalloc out of the loop.<\/em><\/p>\n
The fix is to move our\u00a0stackalloc\u00a0<\/code>out of the loop.<\/p>\n
class C\r\n{\r\n    public void TestMethod(string str)\r\n    {\r\n        int length = 3;\r\n        Span<int> numbers = stackalloc int[length]; \/\/ no warning\r\n        for (int i = 0; i < length; i++)\r\n        {\r\n            numbers[i] = i;\r\n        }\r\n    }\r\n}<\/pre>\n
 <\/p>\n
Configuring Analysis Levels<\/h2>\n
Now that you’ve seen how useful these warnings are, you probably never want to go back to a world without them right? Well, I know that the world doesn’t always work that way. As mentioned at the beginning of this post, these are source breaking changes, and you should be able to take them on in a schedule that works for you. Part of the reason we’re introducing this now is to get feedback in two areas:<\/p>\n
    \n
  1. If the small set of warnings we’re introducing is too disruptive or not<\/li>\n
  2. If the mechanism for tuning the warnings is sufficient for your needs<\/li>\n<\/ol>\n
     <\/p>\n
    Going back to the .NET Core 3.1 analysis level:<\/h3>\n
    If you just want to go back to the way things were before .NET 5 (meaning the warnings you got in .NET Core 3.1) all you need to do is set the analysis level to 4 in your project file. Here is an example:<\/p>\n
    <Project Sdk=\"Microsoft.NET.Sdk\">\r\n\r\n  <PropertyGroup>\r\n    <OutputType>Exe<\/OutputType>\r\n    <TargetFramework>net5.0<\/TargetFramework>\r\n    <!-- get the exact same warnings you used to -->\r\n    <AnalysisLevel>4<\/AnalysisLevel>\r\n  <\/PropertyGroup>\r\n\r\n<\/Project><\/pre>\n
     <\/p>\n
    Turning off just a single rule<\/h3>\n
    If there is a specific warning that you believe is not applicable to your codebase you can use an editorconfig file<\/a> to turn it off. You can do this by either setting the severity of the warning to \u2018none\u2019 from the error list.<\/p>\n
    \"Set<\/p>\n
    Or by selecting \u201cNone\u201d from the lightbulb menu where the warning appears in the editor<\/p>\n
    \"Set<\/p>\n
     <\/p>\n
    Turning off a single instance of a warning<\/h3>\n
    If you want a warning to be on almost all the time and only suppress it in a few instances you can use the lightbulb menu to either:<\/p>\n
      \n
    • Suppress it in source.<\/li>\n<\/ul>\n
      \"Suppress<\/p>\n
        \n
      • Suppress it in a separate suppression file.<\/li>\n<\/ul>\n
        \"Suppress<\/p>\n
          \n
        • Suppress it in source with an attribute.<\/li>\n<\/ul>\n
          \"Suppress<\/p>\n
          Summary<\/h2>\n
          I hope this has gotten you excited for all the improvements to code analysis that you can expect in .NET 5 and please give us feedback about this experience.<\/p>\n","protected":false},"excerpt":{"rendered":"
          Introduction to the new Analysis Level feature shipping in .NET 5 Preview 8<\/p>\n","protected":false},"author":8375,"featured_media":29490,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"quote","meta":{"_acf_changed":false,"footnotes":""},"categories":[685,196,756,3009],"tags":[4],"class_list":["post-29368","post","type-post","status-publish","format-quote","has-post-thumbnail","hentry","category-dotnet","category-dotnet-core","category-csharp","category-performance","tag-net","post_format-post-format-quote"],"acf":[],"blog_post_summary":"
          Introduction to the new Analysis Level feature shipping in .NET 5 Preview 8<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/29368","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/users\/8375"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/comments?post=29368"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/29368\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media\/29490"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media?parent=29368"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/categories?post=29368"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/tags?post=29368"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}