Yesterday I found out the hard way that you should never use a third-party library without doing some preliminary checks. First of all. always check the license: does the author allow you to use his library and if so, how exactly? Second, check whether the library allow partially trusted callers.
Many hosting providers allow you to run your web applications in medium trust instead of full trust. This means that code executing inside your application is not allowed to do a number of things like: opening files, accessing the registry, write to the event log or emitting dynamic classes using System.Reflection.Emit.
Yesterday I was deploying a website to a hosting provider that included the FileHelpers library. If you need to parse CSV files into something you can work with, this is the library for you. It parses CSV files into strongly-typed objects and provides a host of configuration options to do this. Obviously, it has to use some kind of reflection to set property values. At a minimum, it has to call PropertyInfo.SetPropertyValue somewhere. Fortunately, this call is not under any security restrictions.
However, probably for performance reasons, this is not how the FileHelpers library implements setting properties. Instead, it uses the System.Reflection.Emit namespace to build a dynamic class that is then used to set property values. The System.Reflection.Emit namespace is littered with methods that have the SecurityCritical attribute. These methods can therefore only be used in a full-trust environment. Which means that the FileHelpers library can not be used in my website...
The obvious question then is: couldn't you have checked this beforehand? Well, actually I could have. Assemblies that should allow calls from partially trusted callers must explicitly set the assembly-level attribute AllowPartiallyTrustedCallers. The FileHelpers library doesn't have this attribute. Therefore, the first call into the library generates an exception: System.Security.SecurityException: That assembly does not allow partially trusted callers.
This was a bit of a problem since I promised a customer that the website would be live today. There are probably better fixes but what I did was the following (only works for FileHelpers by the way). I downloaded the source code and included it into my solution. This still makes no difference because there are still the SecurityCriticalattributes in the System.Reflection.Emit namespace. The only difference is that errors are now thrown a little later in the process but it is at least possible to call FileHelpers methods. Now I got a little lucky. FileHelpers has been around since the first version of the .NET framework when probably not all necessary functionality ofSystem.Reflection.Emit was available to implement FileHelpers. Anyhow, the code contains some #if NET_1_1 directives that prevent the use of System.Reflection.Emit (instead, System.Reflection is used). So I simply set this compiler symbol, recompiled the code and had a dll that worked.
