.NET Cross-Assembly Performance Hit

Question

I am reading Bill Wagner's book Effective C#. In Item 32 he is advocating for developers to create smaller, more cohesive assemblies that can be reused more readily. However, in that same item he says:

... Extra Security checks also are done across assembly boundaries. All code from the same assembly same has the same level of trust (not necessarily the same access rights, but the same truth level). The CLR performs some security checks whenever code flow crosses an assembly boundary. The fewer times your program flow crosses assembly boundaries, the more efficient it will be... None of these performance concerns should dissuade you from breaking up assemblies that are too large. The performance penalties are minor.

My question is are there extra security checks performed for every method call into Foo.dll, or only the first time the assembly is loaded?

Thanks

Answer 1

The security system in .NET is quite complex. I am not sure the answer is as simple as it may sound at first glance. Even in the event that you have a single assembly, security checks are still performed. When you start an application that has all logic in a single .exe, you don't bypass the .NET security checks for assembly load and verification, nor do you bypass the type inheritance checks. However, once security has been verified for a given scope, it usually does not occur again (there may be some mitigating circumstances that would force re-verification of evidence.)

Multiple assemblies are not going to behave any differently. There may be some additional assembly load cost and initial type access cost, as each new assembly will require those initial security checks. However, those checks will generally pale in comparison to the process of JITting the code itself.

Beyond the basic assembly load and type security checks, you may also have explicit permission demands. Microsofts System namespaces are riddled with Demand and LinkDemand security checks that verify all callers up the stack (demand) or the immediate caller (link demand) have permission to make the call. (Your code should also include such checks were appropriate to validate callers have the appropriate permission, too.) These security checks will happen regardless of where the code lives...locally, in another assembly, or even in an assembly in another app domain. However, once you get into calls made to other app domains or processes, or even to services and other servers, the overhead of marshaling those calls and making connections is orders of magnitude more expensive.

This isn't even the whole picture when it comes to .NET security. Some security checks are more costly than others. Some require a credential, others require evidence, etc. Security isn't something you can shirk...its an essential and critical component of modern software development. I would not worry so much about the cost of security...as it is well implemented and well optimized in the .NET framework and CLR. I would put your effort into ensuring that your application is properly architected and organized. If separating code out into multiple assemblies is logical, reduces maintenance, deployment, and refactoring effort, then its WELL worth the small additional cost to security.

Answer 2

Those security checks are done when the CLR loads the assembly. Once the assembly has been loaded, no further security checks are needed.