Debugging and Deploying ASP.NET applications in a hosted environment: tips and tricks

admin — Thu, 22 Feb 2007 05:49:00 GMT

Deploying a production application to a (cheap) hosted envirionment can be a challenge. You are usually stuck using helm or some sort of control panel to manage your site. Things like partial trust and lack of log access are very limiting. It's easy to get frustrated quickly. I recently ran into a few walls when I deployed 2 production applications to my current host: ASPnix. I'm going to lay out some of the problems that I ran into.

<deployment retail="true" />
This is a setting at the machine.config level that is new to asp.net 2.0. It disables the trace output in pages, turns off the ability to show error messages remotely, and disables <compilation debug="true" />. If your host has retail="true" and you enable debug compilation your site will error and you wont be able to tell why. You will see the normal "turn CustomErrors to Off to see the details of this error....etc" message only you can't turn CustomErrors off. You will pull your hair out. What's even worse is if you have some sort of catch all logging for errors in global.asax the error will not get logged. So...make sure to set debug="false" before you deploy.

While I was troubleshooting my logging (see below) I added a quick and dirty way to see errors:

Global.asax

    protected void Application_Error(object sender, EventArgs e)
    {
        Exception ex = Server.GetLastError().GetBaseException();
        Context.Cache["LastError"] = ex;
    }

ViewError.cs

    protected void Page_Load(object sender, EventArgs e)
    {

        if(Cache["LastError"] != null)
        {
            Exception ex = Cache["LastError"] as Exception;
            Response.Write(ex.ToString());
        }
            
    }

Partial Trust
The majority of asp.net hosts today will have <trust level="Medium" />. ASPnix uses medium trust with a few exceptions that they have set (at least thats my understanding). You should do your homework here. It can be one of those major things that come back to bite you. You code an app that uses some nice 3rd party library only to find out it doesn't work when you deploy to your host. Partial trust prevents you from doing things like making external web service calls, pulling external rss feeds, using reflection, calling certain code or performing some file access. Strongly named assemblies cannot be referenced from a partial trust environment unless they have the AllowPartiallyTrustedCallersAttribute. It is helpful to set the trust level of the app to medium on your development box. You will need to add <trust level="Medium"> under <system.web>. You should be able to see what is throwing the trust exception when you set the level to medium. Make sure you remove it before you deploy or you will get an error even if it's set to medium.

I ran into some specific partial trust problems. The PayPal Controls assembly does not allow partially trusted callers even though the area I was trying to use just outputs glorifed links. I ended up iframing a basic html page that contained the buyitnow buttons. My other major hurdle was the Enterprise Library 2.0. It does not allow partial trust callers either. Fortunately there is a patch available. It's been a while since I did this but I believe these are the basic steps:

Get the patch from gotdotnet.
Copy the patch to your Enterprise Library 2.0 directory.
Build the library.
Run the batch files that build and copy each dll to the parent bin directory.
Add requirePermission="false" to each section like so: <section name="loggingConfiguration"... requirePermission="false" />
If you have trouble consult this excellent article: Using Enterprise Library in ASP.NET 2.0 Partial Trust Mode

De-Velopment : debugging

Debugging and Deploying ASP.NET applications in a hosted environment: tips and tricks