Working Around Shared Hosting

I have been investigating the shared hosting issues with Spring and found that it is not as bad as it initially seems. There are a few steps that must be taken, very similar to those taken from other java ported libraries (eg nhibernate).
Firstly, all calls to GetCompiledPageInstance MUST be replaced with CreateInstanceFromVirtualPath. I have provided the fix for this in a previous thread (http://forum.springframework.net/showthread.php?t=407). This is a must because the GetCompiledPageInstance method has an attribute on it, pretty much killing calls to it unless you are running in full trust mode. On shared servers this will be highly unlikely.

[SecurityPermission(SecurityAction.Demand, Unrestricted = true)]

Now i had thought this had been commited into the main branch of SPring.Web, but the nightly build and the cvs repository on sourceforge both do not have the fix

The second step to take modifing the spring source, is to find the file src\Spring\Spring.Core\Core\IO\FileSystemResource.cs. This file has two calls like this

fileHandle.Directory.Root.ToString();

In the hosting trust mode, this bombs out with a FileIOPermission violation. The reason being, you don't have access to the root directory when you are on the shared host. The Root property of DirectoryInfo has this line in it causing the exception.

new FileIOPermission(FileIOPermissionAccess.PathDiscovery, new string[] { text1 }, false, false).Demand();

My solution is a little hacky at the moment but you get the idea. All it is doing is getting the root folder (ie c: or d:). This propably wont work on a network drive remember.

fileHandle.Directory.ToString().Substring(0, 3);

Third thing to do is to add requirePermission="false" to the configSections section in web.config. If you dont do this you will receive a Configuration security permission exception.

<configSections>

  <sectionGroup name="spring">

    <section name="context" type="Spring.Context.Support.ContextHandler, Spring.Core" 

 requirePermission="false"/>

    <section name="objects" type="Spring.Context.Support.DefaultSectionHandler, Spring.Core" 

 requirePermission="false"/>

  </sectionGroup>

</configSections>

The last item on the list is probably the most obscure, and i will try to explain and give some background:

dll's can be signed, which gives them a strong name and a hash, which stops them being modified and re-distributed.
strong named dlls can be registered in the GAC.
From the GAC, dlls can be configured to run in full trust, depending on your .net framework configuration. (see somewhere in control panel -> administration tools).

When you run a web application in anything but full trust, all the dlls in the bin directory run in a partial trust mode.
Strong named assemblies that are NOT in the GAC but in you bin directory, can not by default be called from a partial trusted assembly

So in this case i have my project dll, spring, nhibernate and log4net in the bin directory, plus any dependant dlls. nhibernate and log4net are strong named, but i can only call log4net from my app, not nhibernate. Why is this? its because log4net has an assembly level attribute on it.

[assembly: System.Security.AllowPartiallyTrustedCallers()]

This attribute allows my partially trusted application to call into it without throwing an exception. Details can be found on msdn, its something to do with LinkDemand.

Now it gets tricky, that would mean all the dll's that i have in the bin directory need this attribute. How would i do this?, I could get all the sources for them and recompile, but what happens if i can't get the source, or i have a 3rd party app that is proprietary. I do the following instead:

1. get all the dll's and disassemble them
2. add the AllowPartiallyTrustedCallers attribute to them in the MSIL file
3. remove all signing code from the assembly
4. remove all public keys and hashes from the assembly
5. update any extern assembly declarations, by removing the public hash requirement
6. reassemble the dll's again.

What does this do? It removes all strong names from the assemblies and also updates the references to not require the strong named versions.
As we dont have the keys that sign the dll, we can't resign them, but we can remove the signing altogether.
We could resign them all with new keys that we created and update the references, but that sounds like a lot of work for no gain.
We are going to be running in partial trust mode so we just don't need strong named assemblies.
This process probably wont work in all circumstances mind you.