Zip Component, Email Component, Encryption Component ActiveX Control for Zip Compression .NET Components for ASP.NET
ActiveX and .NET Components for Zip Compression, Encryption, Email, XML, S/MIME, HTML Email, Character Encoding, Digital Certificates, FTP, and more ASP Email ActiveX Component


Index of Chilkat Blog Posts

October 13, 2006

3rd Party .NET Components in ASP.NET 2.0 Shared Hosting w/Medium Trust

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:

...
	<CodeGroup
	    class="FirstMatchCodeGroup"
	    version="1"
	    PermissionSetName="Nothing">
		<IMembershipCondition
		        class="AllMembershipCondition"
		        version="1"
		/>
		<CodeGroup
		    class="UnionCodeGroup"
		    version="1″
		    PermissionSetName="FullTrust"
		    Name="Chilkat_Components"
		    Description="This code group grants the ChilkatDotNet2.dll full trust">
			<IMembershipCondition
			        class="StrongNameMembershipCondition"
			        version="1″
			        PublicKeyBlob="0024000004800000940000000602000000240000525341310004000001000100B535D66DF2C8716055B05EB7F3D332451F89D5A293FC1F9B0244D4EC465FA04AEEC12D5F9731296D95334B311D4015C0567A5CE42475E1192E11798F8463B624FA6E655737207ACAFE2D68F67C2337BAD527BF4D1FB44077845BF93260FC0FFCD0EB30FE7C7290463697F235B71979478BB33DE14B9F73DBAA5402A2767A1ABE"
		/>
		</CodeGroup>
	
		<CodeGroup
		        class="UnionCodeGroup"
		        version="1″
		        PermissionSetName="ASP.Net">
		    <IMembershipCondition
		            class="UrlMembershipCondition"
		            version="1″
		            Url="$AppDirUrl$/*"
		    />
		</CodeGroup>
…


Privacy Statement. Copyright 2000-2011 Chilkat Software, Inc. All rights reserved.
Send feedback to support@chilkatsoft.com

Components for Microsoft Windows XP, 2000, 2003 Server, Vista, Windows 7, and Windows 95/98/NT4.