Since changeing web hosts I have not been able to get dasBlog running in the new environment. The host server is setup so that .Net code runs at medium trust level and won’t allow me to override the trust settings. As anyone who has tried to get dasBlog to run at medium trust knows, it just isn’t possible out of the box. To make life even more difficult Asp.Net returns an incomplete and ambiguous SecurityException:
Description:
The application attempted to perform an operation not allowed by the security policy. To grant this application the required permission please contact your system administrator or change the application’s trust level in the configuration file.
Exception Details:
System.Security.SecurityException: Security error.
Source Error:
|
The stack trace that is included provides no help in solving the problem and actually sent me on a wild goose chase trying to solve completely unrelated issues.
I have started to dig into this to try and see if I could find a quick fix for it with googles help. So far I haven’t found a quick fix but I have found a few other things that may lead me to a solution… First of all I have seen a few forum posts and blogs referring to reflection used by serialization as part of the problem. But I have managed to get XmlSerialization to work without chainging the serializer or trust level of the application so it doesn’t seem to be the XmlSerializer that is causing the exception. I changed the virtual directory settings on my local machine so that dasBlog runs under .Net 2, this provided me with a much clearer exception. dasBlog has a custom XmlTextReader called XmlNamespaceUpgradeReader which inherits fom XmlTextReader. The only problem is that XmlTextReader has a security demand for exicit inheritance permissions [PermissionSet(SecurityAction.InheritanceDemand, Unrestricted=true)]. Running under medium trust you don’t have the required permissions. Changing all XmlNamespaceUpgradeReader references to XmlTextReader allowed the deserialization of SiteConfig (and all other serialized data) to run.
The next problem was that even though the site serialization was working dasBlog stilled just returned a big fat exception. Another wild goose chase followed trying to solve new unrelated issues, but working on them gave me a flashback to a problem I solved a year or so ago while setting up NGallery on the same host. Calling strong named assemblies from partially trusted code can also be a show stopper if the signed assemblies don’t allow partially trusted callers. Two assemblies in dasBlog cause this problem SharpZipLib which is used for HttpCompression and BasicFrame BasicDatePicker, neither are compiled with the AllowPartiallyTrutedCallers setting. Removing references to these solves the rest of the problems that I was experiencing. Unfortunately the fixes disable some functionality in dasBlog and may have unexpected effects on configurations other than mine.
I am planning on following up on this post with detailed instructions on implementing the fixes and maybe som attempts to restore full functionality.
References on the web that sort of showed me in the right direction:
http://choirulamri.or.id/archives/94
http://www.hanselman.com/blog/CommentView.aspx?guid=a7e58fa0-9390-4270-bab3-83ea2e969352
http://www.hanselman.com/blog/CommentView.aspx?guid=4dd4573a-1fee-4680-b28e-983271bd3ae8
http://www.jwerx.com/blog/CommentView,guid,31c5f741-3d52-46a3-beb5-b934dea73423.aspx
http://dasblog.us/viewtopic.php?p=761&sid=b87a704cc1fffacabcb0bfff2660aac9
