Many shared hosting providers (in this case Mosso) run your ASP.NET applications in a medium trust or modified medium trust environment to reduce security risks. This causes issues with certain techniques and components that require permissions removed by medium trust.

One of the biggest issues other than the actual restriction of permissions is the restriction of partially trusted assemblies calling fully trusted code. By default, if an assembly is strong named, partially trusted assemblies (i.e. the application assemblies in your app running under medium/partial trust) can't call it. This hits many open source components such as iBatis and NHibernate. The workaround to this is to add the AllowPartiallyTrustedCallers assembly level attribute. This will mark the assembly as safe for calling by partially trusted assemblies.

Here is an example of how to modify iBatis to support this:

  1. Download the iBatis source from the iBatis website:
  2. Extract the source .zip to a folder
  3. Open the IBatisNet.2005.sln solution in VS.NET
  4. For each project in the solution, open it's AssemblyInfo.cs file
    1. Add this using statement at the top of the file: "using System.Security;"
    2. Add this attribute at the bottom of the file: "[assembly: AllowPartiallyTrustedCallers]"
  5. Right click on the solution and select "Configuration Manager..."
  6. In the "Active solution configuration" dropdown, select Release
  7. Uncheck all of the Test projects
  8. Click OK
  9. Build the solution

Or you can download the compiled assemblies:

Enabling NHibernate for medium/partial trust is a similar procedure. If there is enough demand I will present steps and compiled assemblies for it as well.

As for the permission restrictions, most shared hosting providers don't actually run in medium trust as this restricts many useful things such as Reflection etc. One example I've run into recently is Mosso's modified medium trust. They take medium trust, which consists of the following denied permission restrictions:

  • Call unmanaged code.
  • Call serviced components.
  • Write to the event log.
  • Access Microsoft Message Queuing queues.
  • Access ODBC, OleDb, or Oracle data sources.
  • Access files outside the application directory.
  • Access the registry.
  • Make network or Web service calls (using the System.Net.HttpWebRequest class, for example).

And then Mosso adds back in the following allowed permission to come up with "modified medium trust":

  • WebPermission Unrestricted="true"
  • OleDbPermission Unrestricted="true"
  • OdbcPermission Unrestricted="true"
  • SocketPermission Unrestricted="true"
  • ConfigurationPermission Unrestricted="true"
  • ReflectionPermission Unrestricted="true"

This is still rather limiting, but at least you can get most things done as long as you can call into the necessary assemblies without getting exceptions as discussed in the workaround section above.


Comment by SKC

May be a little bit off-topic.

If we want to access an external Oracle DB from a ASP.NET application running on MOSSO, is it possible?

If so, since we only have FTP access, how do we install Oracle/ODBC specific stuff?

Comment by programcsharp

You may be able to do Oracle on Mosso if you use an entirely .NET Oracle database provider that works with the permission set Mosso provides. You won't be able to get all of the typical Oracle Client stuff set up on Mosso, but some providers are out there that can access Oracle directly via tcp/ip.

You also would have to host the Oracle DB somewhere else and connect to it via tcp/ip.

Comment by Dave

Works perfectly. Thanks for the tip. I just plugged your iBatis DLLs right in, over top of my current ones, and they worked fine.