Cook Computing

I've just come across mention of an XML-RPC.NET problem on the clyx development blog. They have a Community Server installation and were seeing exceptions with this message:

Operation could destabilize the runtime.

What the? Sorry, could you repeat that? I am so learning to hate that message. A haiku message would be more useful. The message may be mysterious, but our experience indicates that it is somehow related to mixing .NET 1.1 and .NET 2.0 assemblies in the one \bin directory. (Shades of DLL Hell all over again...)

We saw this in both the Exceptions Report and Event Log. It happened when using a desktop blogging tool to access the CS Metaweblog API. We also noticed that an assembly wasn't loading - the ubiquitous and very handy XML RPC support library from Cook Computing. This seemed to be due to it being strongly named. By grabbing the source, building it in .NET 2.0 and removing the key file reference (alternatively, adding your own key), we were able to get it going.

So we got this far OK... let's check that log one more time....no more runtime destabilization.. YAY!

A post on a Microsoft ASP.NET forum seems to confirm there is a possible issue with using assemblies built for .NET 1.1 in an ASP.NET 2.0 application:

We saw this back towards the end of Whidbey for a case where 1.1 DLLs were being used in an ASP.NET 2.0 app. Apparently the 1.1 compilers for C#/VB.NET had some boundary cases with the IL they emitted. In 2.0 there were low-level changes in the CLR that made some 1.1 code unverifiable - which leads to the exception you are seeing. Unfortunately I can't claim to understand what it was the CLR changed - I just know we saw it.

In our specific case it was a problem with a C# switch statement that had more than 8 conditions - underneath the hood the C# compiler in 1.1 emitted IL code that became unverifiable in 2.0. I don't see any switch statements in your code above so that's not going to be the specific problem.

To track down the problem, you should try the old fallback of chopping out all the code except the first line. Then run the app - see if it fails. Then uncomment the second line code code - run the app - see if it fails. Rinse and repeat. That's literally how we tracked down the issues on our team.

The error message is coming from an instance of System.Security.VerificationException. The clyx problem manifested itself when they migrated from development to their production hosting site and went from running their code under full trust to medium trust. This is because their hosting service, like many others in shared hosting environments, force ASP.NET sites to run under medium trust to prevent applications from causing any damage to the system or to other sites on the same machine. When running with medium trust code is verified unlike full trust where verification appears to be skipped. I didn't realize that in a full trust environment, i.e. code running locally on a system with default settings, code is not verified. For example this program from the .Net Security Blog will run locally even though PEVerify fails it:

// Compilation:
// ilasm -nologo -exe test.il

.assembly extern mscorlib {}
.assembly test { .ver 0:0:0:0 }

.class public Test extends [mscorlib]System.Object
{

    .method public static void Callee()
    {
        .maxstack 1
        ldstr "In Callee()"
        call void [mscorlib]System.Console::WriteLine(string)
        ret
    }

    .method public static void Main()
    {
        .entrypoint
        .maxstack 1
        ldftn void Test::Callee()
        calli void ()
        ret
    }

}

I've not been able to reproduce clyx's problem but I am seeing the following error when running XML-RPC.NET in anything but Full Trust:

Request for the permission of type 'System.Security.Permissions.SecurityPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.

The exception is thrown when MethodInfo.Invoke is called. I need to do some more investigation.

Following my recent Skye post Mark Smith at Information Patterns emailed me:

You can also get free wifi at the An Tuireann arts centre. They also do good soup which the library doesn't. :-)

Coding Horror has a piece on Text Columns: How Long is Too Long? The post quotes some research results which probably aren't really all that applicable to code because its not ordinary text and might look a bit strange if right-justified. Still, its a topic worth thinking about. Is there an optimum max line length for code, maybe different for each programming language, or is it ok to keep typing to the width of the editor viewport or even beyond?

On the whole I tend to write code with line length no greater than 80 columns (I use guidelines in Visual Studio as I described here). Ok, the first paid coding I ever did was in COBOL, so that may have corrupted me for ever, but there are advantages to keeping line length in the order of 80 to 100 characters max width. You can have two editor windows side-by-side on single screen and see all the code in both windows. Similarly when using tools to view the diffs between two files. You're not lured into excessive levels on indentation and avoid the Arrow Anti Pattern. You can print code without using landscape orientation. You tend to write complex conditional statements over multiple lines which makes them easier to understand. And You can read code without having to move your head side-to-side as if you're watching a tennis match.

I find it a bit depressing when I see a developer working on a wide screen with Visual Studio maximised, the code editor window stretched across most of the screen, and typing in lines of code which take up all the available width. That suggests a lack of insight into what they are doing. The size of their screen is determining how their code looks, to the likely detriment of the code. Are lines of code 200+ characters wide all that readable? How comprehensible is code when you have 10 or more levels of indentation? Say they're on a 19in screen now. What happens when they move to 24in. Do they now automatically move up to 250 character lines? Do they now use more levels of indentation in nested conditional or loop statements without any conscious decision to do so?

But the thing that irritates me the most is when I revisit my own code which was neatly crafted to fit into 80 columns with minimal use of indentation and find that someone has made changes, adding a few lines of 150 to 200 characters long. Aargh!

I've investigated a report of problems with the Syndic8 XML-RPC API where requests from XML-RPC.NET were failing with "The server committed a protocol violation. Section=ResponseStatusLine". It looks like the Syndic8 server is returning a spurious linefeed after the body of the response, i.e. if the Content-Length header has a value of 854 then there is a linefeed in the HTTP response at offset 854 from the start of the content.

This may not cause a problem if your client uses a separate connection for each request, but XML-RPC.NET uses the default KeepAlive setting of the underlying WebRequest object which means that a single connection is used for multiple requests. Presumably that spurious byte messes up the parsing of the status line at the start of the following HTTP response and causes the above error.

The workaround is to switch off KeepAlive:

ISyndic8 syndic8 = (ISyndic8)XmlRpcProxyGen.Create(typeof(ISyndic8));
(syndic8 as XmlRpcClientProtocol).KeepAlive = false;

Just back from a two week vacation on the Isle of Skye. We had lots of sunshine and very little rain, which is unusual for Skye. The panorama above is an evening view from the cottage we rented in Uig; the one below is an early morning view from the other side of the bay.

The ferry from Uig sails to Lochmaddy on the Isle of North Uist and to Tarbert on the Isle of Harris, both in the Outer Hebrides. We will be staying in Tarbert later this year.

In case you need an internet connection while on Skye, I discovered that in Portree the public library has several free internet terminals (but the library has limited opening times) and the tourist office has a single terminal starting at £1 for 20 minutes.