Most 3rd Party .NET components, including Chilkat, provide functionality that is not allowed by Microsoft’s "Medium Trust" level for ASP.NET 2.0. The problem is that many shared hosting environments lock the trust level on the web server to Medium Trust. If you upgrade your ASP.NET 1.1 application to ASP.NET 2.0, you’re likely to find that it breaks. Your application itself may be accessing resources not allowed at the medium trust level, or you may be using 3rd party .NET components or even ActiveX components that do the same. It’s difficult *not* to violate the medium trust level. For example, TCP/IP socket communication is not allowed which makes it impossible to communicate with FTP servers, POP3 servers, IMAP servers, etc. WebPermission is restricted to "Connect to origin host (if configured)" so utilizing external Web Services is out of the question.
There is a solution, and it’s easy. However, you’ll need the help of your shared web hosting company. The solution is for the web hoster to modify the default medium trust level by allowing DLLs from well-known and established component vendors to run at full trust. (I’ll show you how it’s done later in this article.)
A .NET component vendor should provide a DLL that is (1) strong-named and (2) has the APTC attribute (AllowPartiallyTrustedCallers). The reason for needing APTC is that (usually) the web application that calls the trusted DLL is not fully trusted.
Giving Full Trust to a Strong-Named Assembly in a Medium Trust Environment
To modify the medium trust configuration, edit the web_mediumtrust.config file found
in the Windows\Microsoft.NET\Framework\v2.0.****\CONFIG directory.
At the beginning of the CodeGroup section, insert a CodeGroup fragment
for the DLL to be trusted. The DLL is trusted based on the PublicKeyBlob (thus
the DLL must be strong-named and signed). The bold text is the
text that should be inserted to give ChilkatDotNet2.dll full trust:
Description="This code group grants the ChilkatDotNet2.dll full trust">