After all the work that has been done on the .NET Core side of things, it seems like this is Microsoft’s official christening of their successor to the .NET Framework. So, anyone working on anything new, or anything wanting support in the distant future, will probably be trying it out.<\/p>\n\n\n\n
Since its release has coincided with a number of efforts I’m making in the creation of an Omnified<\/a> technology stack, I made sure to switch to it right away so I could start working with it. I’ve been buried in too much assembly code and older .NET Framework application code as of late, so I had a lot of makeup learning to do in order to start to fully grasp all the changes that came with .NET Core development.<\/p>\n\n\n\n One thing I became familiar with rather quickly was the new way that code analysis was being done, in particular the new Roslyn analyzers<\/a> that ship with the .NET 5.0 SDK.<\/p>\n\n\n\n Many of the rules are, for some reason, essentially disabled by default. I enabled them so I could see (with masochistic glee) what would be flagged. Not long after, I get hit with the following:<\/p>\n\n\n\n Right. Of course! I’ve always put my P\/Invoke declarations into a NativeMethods-styled class. But I didn’t this time, with a new project targeting .NET 5.0, for reasons which caused me to be surprised to see it being flagged by Code Analysis. It was my belief that this practice would now be null and dead with the latest .NET.<\/p>\n\n\n\n Why did I think this way? We’ll get to my reasoning in a bit. First, let’s just quickly go over what CA1060 <\/strong>is and what the whole NativeMethods rigmarole is all about.<\/p>\n\n\n\n If we want to call into some unmanaged code, we need to make use of P\/Invoke, also known as Platform Invocation Services, via the use of a the DllImportAttribute<\/a>. If any methods decorated with this attribute exist in your code outside of a class named either NativeMethods<\/strong>, SafeNativeMethods<\/strong>, or UnsafeNativeMethods<\/strong>, you will trigger a CA1060 Code Analysis warning<\/a>.<\/p>\n\n\n\n The recommendation to corral the P\/Invoke methods into one of these classes is mainly driven by Code Access Security<\/a> concerns. If operating in a CAS environment, .NET code can only execute unmanaged code if it has the UnmanagedCode<\/strong> permission.<\/p>\n\n\n\n Ensuring that a particular caller has this permission requires a full stack walk when the P\/Invoke code is called. This can be expensive in terms of performance. <\/p>\n\n\n\n The way to get around this hit to performance is through the use of the SuppressUnmanagedCodeAttribute<\/a>. Throwing this on a class causes the permission check to no longer occur, avoiding the stack walk. It will also basically allow for even potentially untrusted code to be able to call these methods.<\/p>\n\n\n\n So, in order to make it clear which code is using this attribute, with all of its potential security implications, the NativeMethods triad of classes was born.<\/p>\n\n\n\n I tend to ignore what Microsoft says, and look at what they do<\/em>. And indeed, you will find throughout the (soon to be old) .NET Framework class libraries a faithful following of this practice.<\/p>\n\n\n\n No. It’s a practice that will eventually fade into antiquity. There simply is no reason to do so anymore. And that’s because of a big change that came with .NET Core: the dropping of Code Access Security<\/a>.<\/p>\n\n\n\n I always viewed Code Access Security as a fine example of overengineering that resulted in a silly amount of unnecessary work and consideration, and I’m simply overjoyed to see Microsoft chucking it out the window.<\/p>\n\n\n\n The purpose behind the different NativeMethods classes was entirely<\/em> related to security implications that arose with Code Access Security and the SuppressUnmanagedCodeAttribute. Thus, my surprise with this code analysis rule still being a thing in the new .NET 5.0 SDK.<\/p>\n\n\n\n Still, it makes some sense to have some sort of organization behind your P\/Invoke declarations. Also, as I said before, I tend to ignore what Microsoft says and look at what they do<\/em>. So, in the new .NET 5.0 library sources, is Microsoft still using NativeMethods-styled classes?<\/p>\n\n\n\n![\"Shows](\"https:\/\/badecho.com\/wp-content\/uploads\/2020\/11\/Net50Analyzers.png\")
CA1060: Move pinvokes to native methods class<\/code><\/pre>\n\n\n\nNo Native Methods Outside of NativeMethods!<\/h2>\n\n\n\n
But Must I Use NativeMethods-Styled Classes with .NET 5.0?<\/h2>\n\n\n\n
![\"Shows](\"https:\/\/badecho.com\/wp-content\/uploads\/2020\/11\/Net50Interop.png\")