Last week I was extending the Enterprise Library Logging Application Block to include some extra information when logging some data. I wanted to validate incoming parameters so I added a reference to a helper library I created that contained a set of validation extension methods.
Everything compiled nicely but when I tried to run the application it failed with the following error message:
“Attempt by security transparent method ‘FormattedDatabaseTraceListener.ctor()’ to access security critical method ‘StringExtensions.IsEmpty(System.String) failed.’”
This error is caused by our good old friend CAS(=Code Access Security). Most people never used CAS because it was way to complex to debug issues. In .NET 4.0 it got replaced by a much simpler security model (but I don’t think anyone will give it a second try). But in this case Microsoft Patterns and Practices team gives the good example and is using it in the Enterprise Library codebase.
If we look inside the AssemblyInfo.cs file, we see that the assembly is marked with the SecurityTransparent attribute. This means that the code is transparent; the entire assembly will not do anything privileged or unsafe.
The problem is that the moment you start adding these security attributes, you also have to configure the CAS for any other assemblies you call.
In this case I don’t care about CAS, so I just removed the [assembly: SecurityTransparent] line from the AssemblyInfo.cs file.