Archived Posts from this Category
Archived Posts from this Category
It’s been quite a while since the last ‘Afternoon Tea’ post, and there have been quite a lot of significant announcements in the past few weeks, coupled with my being busy at work which has resulted in me building up quite a backlog of links which I really wanted to include in a Morning Brew. This post is my attempt to ‘clear the decks’ and get caught up again, and also provides the perfect excuse to do a link roundup of DDD South West which I had the pleasure of presenting at at the end of last month.
Disaster struck this morning - I pressed post, waited until the page reloaded and shut my laptop as usual, but for reasons unexplained the post never made it onto the site - So here is today’s edition, a little later than planned - at least its still morning *somewhere* in the world!
Thanks to Libor or letting me know something was wrong
Update: In my haste to resurect today’s post a ’smart quote’ snook into some HTML merging Sankarsan & Jon Skeets links together - fixed now - thanks to EF for letting me know
When you first request a page from the an ASP.NET application, the .NET framework takes the ASPX file and generates code to actually execute the page. This code is then compiled by the framework and the results of the compilation are stored in the Temporary ASP.NET files directory within the framework directory (usually located in c:\windows\Microsoft.NET\Framework). When the ASPX of the compiled DLL changes this code is re-generated and recompiled.
On a server that hosts lots of ASP.NET applications this store of temporary compiled code can occupy a considerable amount of space. On machines with a limited amount of space on their OS partition this can begin to cause problems. Thankfully the ASP.NET framework does allow the location of this directory to be specified as a custom location.
As with most server wide settings you need to make a change to the Machine.Config (for .NET 1.1) or Machine wide web.Config (for .NET 2). The crucial part of the configuration is the Compilation element within system.web. The compilation element has an optional attribute called tempDirectory that allows a new directory location to be specified overriding the default setting of %FrameworkInstallLocation%\Temporary ASP.NET Files.
One thing to watch out for when making this change is the file permissions on your new Temporary ASP.NET files - copying the permissions from the original location will do the trick nicely.
One of my basic assumptions about the .NET framework was proved incorrect last week. Up until then, I had believed that when you are using the built in framework classes for exposing web services you were always safe when it came to the output being valid XML. Sadly that turns out to be untrue, and to make matters worse, .NET will happily output XML over a web service even its own .NET web service clients can’t read.
There are certain characters that are forbidden from being in XML as per the official specification. These characters are the low ascii characters such as NULL, EOF etc. Its important to note that this is not a case of unescaped/unencoded versions of this character being disallowed, the encoded characters are also disallowed.
The problem with this isn’t that the .NET framework doesn’t understand these rules - it manages just fine when it comes to acting as a client to a web service serving these characters in content, throwing nice exceptions explaining that these characters are invalid. Additionally, the XML Text Reader has a property ‘Normalization’ which causes the XML reader to be more liberal and ignore invalid characters - but this option is not used within the automatically generated Web Service Client.
This problem isn’t limited to just the web services, standard XML serialisation also experiences the same problems. Here are bits of code that illustrate the problem:
public string InvalidCharacter()
return "" + (char)4;
public class MyClass
public string Test = "" + (char)0;
public static void Main()
MyClass c = new MyClass();
System.Xml.Serialization.XmlSerializer xs = new System.Xml.Serialization.XmlSerializer(typeof(MyClass));
System.Text.StringBuilder sb = new System.Text.StringBuilder();
System.IO.StringWriter sw = new System.IO.StringWriter(sb);
System.IO.StringReader sr = new System.IO.StringReader(sb.ToString());
c = (MyClass)xs.Deserialize(sr);
catch (System.Exception ex)
The little console application gives output like this:
<?xml version="1.0" encoding="utf-16"?>
<MyClass xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
System.InvalidOperationException: There is an error in XML document (3, 12).
System.Xml.XmlException: '.', hexadecimal value 0x00, is an invalid character.
Line 3, position 12.
Unfortunately I haven’t yet found a fix for this - my only solution is to work around the problem by ensuring that these invalid characters can’t get into the system in the first place or clean the text on the get of each property of the serialized objects.
Things like this really worry me - our frameworks shouldn’t be outputting things that they can’t read - let alone outputting things that completely contravene the specifications. As always, any suggestions on an alternative solution to this problem are welcome.
Today I encountered a strange problem with IIS6 restarting without notice on a server that had recently had the .NET Framework 2.0 installed on it. In our particular case the problem was made worse by the fact that the IIS restart was unsuccessful leaving the server in a some what crippled state. We traced the problem to clicking on the ASP.NET in the IIS Management MMC, not making any changes to the settings, then clicking OK on the properties dialog.
Usually making a change to the version of ASP.NET will cause a restart of IIS (and there are alternative ways that avoid the restart), however in this case it seems as though just viewing the tab and then clicking OK was enough to cause ASP.NET to restart the IIS Service. I’ve still not discovered precisely why this is happening, but for the time being I wanted to implement a work around to avoid the problem by disabling the ASP.NET Tab.
I thought doing this would be easy, after all enough people seem to have problems with the tab not being there. Common causes of the tab being missing seem to be running the IIS MMC on x64, or having installed an earlier beta of .NET 2.0. The fixes in most cases seem to be modifications to the registry or re-running aspnet_regiis -i to re-register ASP.NET.
While it is possible that by fiddling with the registry I could break the ASP.NET tab that didn’t seem to be a good solution, so I carried on digging. It turns out that the ASP.NET Tab is implemented as an MMC Snap-in extension, and can be disabled with two clicks of the mouse once you’ve found the setting. So, to disable the ASP.NET tab within the ASP.NET management MMC:
Now when you start the IIS Manager the ASP.NET tab won’t be there.
Sadly the tab is still there in the Computer Management MMC (Computer Management > Services And Applications > Internet Information Services), and looking at the computer management MMC in the same way as above does not yield the same choice of Extensions, so if anyone knows how to influence Computer Management in the same way, please let me know!