Andy @ Work

Monday, September 25, 2006


My company has recently signed a maintenance agreement for a web system written by a third party software company. This third party is based in Queensland are doing quite well for themselves.

The code is strange at best, and in some places just downright confusing.....but today I came across this little pearler:

child = xml.CreateElement("creditFlag");
child.InnerText = false ? "yes" : "no";

The problem is, it didn't just show up once but in a few places, sometimes with the conditional hardcoded to true instead of true. WTF?

As a side note, I tried to post this snippet to The Daily WTF but I just couldn't work out how to submit something to them. Maybe they don't take public submissions or something.

Monday, February 06, 2006

MSBuild and NAnt

At work we've been moving more and more projects from VS2003 to VS2005, and except for our initial forey into web sites (projectless the journey has been relatively smooth.

Until we tried to execute our NAnt build scripts.

It appears that NAnt's task does not support VS2005 solutions. I knew this back in November but thought that the NAnt guys must be busy and would have a fix for the problem within the month.

Then came December.....January....and finally February and still the solution task does not support VS2005 solutions.

(There is a way to get it to work....and I'll post on that later once I'm happy with the solution...for the mean time read on).

I started to think that NAnt was dead. I also started to wonder if I should be porting our existing NAnt scripts over to MSBuild. There are two main reasons to do this.

1. MSBuild is packaged with VS2005, so it should be kept up to date with future versions of VS.
2. MSBuild can be used from within the IDE, making it feel more closely coupled with the development life cycle.

See my NAnt scripts are not overly complicated. In fact I think as far as the 'build' goes they are very simple, just calls the task and makes sure that the Build outputs are placed in a certain folder.

However, our build process is very SCM related. We check out, check in, label, branch, update our dependencies from other binaries in our SCM. Stuff that took me a while to write and is used frequently (especially updating dependencies to the latest release or nightly build).

So to port to MSBuild is not a trivial process.

Anyways, after all that I decided not to port but to try and get NAnt to work with VS2005. (After reading this post, I'm glad I did).

When I've polished my solution I will post it here.

Tuesday, January 24, 2006

Thank God for Reflector

One of the projects I'm working on requires integration with an online credit card gateway. The interface is very simple, of the single page to post parameters at variety.

So I implemented by solution using good old faithful System.Net.WebClient. Imagine my surprise when UploadValues was raising the following exception:

The server committed a protocol violation.
Section=ResponseHeader Detail=CR must be followed by LF

I had a quick look at the raw response, and sure enough the response header and body were only separated by a single CR instead of CRLF (why an IIS 6 server is responding in this fashion I have no idea).

Since I have no control over the external gateway (even though technically they are sending malformed responses) I thought that I could implement my simple UploadValues() method using the Socket class.

That I idea seemed good for about 5 seconds when I recalled that I'm calling a web page over SSL, making the work of implementing UploadValues a lot more difficult.

As the title of this post suggests, I fired up Reflector to see the code that was raising this exception to determine if there was a work around. 30 minutes later I found one (after I disassembled the entire System.dll to a temporary folder). System.Net.WebHeaderCollection has two methods for parsing response headers:


ParseHeadersStrict was raising the exception. But plain old ParseHeaders looked to be a little more forgiving.

So I used Reflectors analyzer to determine who was calling ParseHeadersStrict and discovered the System.Net.Connection.ParseResponseData() method. ParseResponseData makes a decision to call either ParseHeaders or ParseHeadersStrict based on the value of SettingsSectionInternal.Settings.UseUnsafeHeaderParsing (found in System.Net.Configuration).

By this point I can smell victory. Using VS.Net 2005's excellent intellisense for configuration files, I added the following:

<httpWebRequest useUnsafeHeaderParsing="true"/>

Without Reflector I don't know if I would have ever found the solution so quickly.

Thursday, January 05, 2006

Aaaaaaah....thats why my FormsAuthentication didn't work

One of the projects that I'm currently working on involves an ASP.Net 2.0 site which needs to open an IFrame onto a different ASP.Net 2.0 site. Yesterday I noticed that after logging into my wrapping site, any attempt to navigate to another section of my site that required authenticated users would result in me having to authenticate again.

To cut a long story short, the problem I was having only presented itself when I tested the website while being hosted by the ASP.Net Development Server (hosting in IIS was fine). Well the problem came down to the <iframe>. Because I was authenticating with two sites (one wrapping the other) and they both were setting the value of the .ASPAUTHX cookie AND they were both hosted within the ASP.Net Development Server, the wrapped website was destroying my wrapping websites authentication ticket.

Changing the forms configuration element in web.config to use a different name for this cookie solved the problem.

The reason the problem only presented in the ASP.Net Development Server was due to my IIS server being referenced by a FQDN as opposed to localhost. Hence my wrapping .ASPAUTHX cookie had a different host value to my wrapped websites authentication ticket, and so was being overwritten.

You live you learn.

Thursday, December 01, 2005

Topological Sort

Yesterday my domain layer was having problems determining the order to commit objects to the database. The problem was foreign key referential integrity. It seems that SQL Server doesn't support a mechanism to delay the checking of foreign key constraints until the transaction is committed. If it did you could perform your inserts in any order, commit the transaction, and THEN let SQL check the foreign keys.

For example say we have four classes:

class Customer {...}
class ShippingAddress {...}
class Order {...}
class OrderItem {...}

and lets say that the underlying Order table has a foreign key to both the Customer and ShippingAddress tables, and that the OrderItem table has a foreign key to the Order table. If I create all these objects in one transaction (for the sake of my point), I have to make sure that I insert the Customer object before Shipping Address, both of which have to be inserted before the Order object which has to happen before the OrderItem object(s).

So I did a bit of reading in Martin Fowlers Patterns Of Enterprise Application Architecture and it seemed that Unit of Work combined with some Attributes/MetaData and a Topological Sort would be required.

Essentially I created an Attribute called ForeignKeyAttribute that accepts a single Type in its constructor. This was my way of signalling that one class had foreign key dependencies on one or more other classes.

class Customer {...} // No foreign keys

class ShippingAddress {...}

class Order {...}

class OrderItem {...}

I then created a collection whose Enumerator would treat the collection as a Directed Acyclic Graph (DAG) and perform a Topological Sort (ie the order that the Enumerator returned items).

So when Commit() is called on my Unit of Work object, each object Type that is in my 'to be inserted' collection is added to my DirectedAcyclicGraph object, and I then enumerate through the graph, to work out in which order objects in my 'insert collection' should have their Commit() method called.

Later on I'll post some better code samples to demonstrate my point better.

Tuesday, November 29, 2005


Have you checked out Pandora yet? If not … do it now. Simply amazing.

Traps to look out for when implementing IXmlSerializable for a Web Service

I’ve been working on this new project in .Net 2.0, and am loving the flexibility that the IXmlSerializable interface gives me. Before this interface, I either had to let the XmlSerializer dictate the design of some of my business layer classes, or create very a series of Data Transfer Objects (DTO’s). Most of the time I've gone down the DTO path so that other users of my business layers didn’t accidentally start using methods that were not designed for them to use.

Anyway. After implementing a couple IXmlSerializable interfaces on what I would consider complex types (not very complex ~ just not simple) I have come across the following traps/tricks.

  • WriteXml When you implement this method, make sure you include the default namespace in your Write... methods. This has caused me so many hassels in the past. Its easy to forget, but if you don't do it you won't be able to send serialized types to your consumers.

  • DateTimesWhen serializing and deserializing DateTime’s you normally use the XmlConvert class. Make sure you use the ToDateTime method that will take a XmlDateTimeSerializationMode enum as a parameter, and set that enum to RoundtripKind. Otherwise you will get a lot of FormatExceptions when deserializing a Datetime on your side of the webservice.

  • Try to avoid using attributes in your schema over elements. Personally I think that attributes look neater than a whole string of xml elements, but its easier to read elements using the XmlReader than it is to using Attributes.

If I have time I would like to investigate that third point a little more to confirm that there is problem with the order in which enum elements in the schema are defined.

Wednesday, November 23, 2005

Problems with InternalsVisibleToAttribute?

Have you ever had this error when using the InternalsVisibleToAttribute?

Friend assembly reference 'UnitTest' is invalid. Strong-name signed assemblies must specify a public key in their InternalsVisibleTo declarations.

BUT the assembly which contains the attribute isn’t being strongly signed?

More than likely you are dealing with some code that was ported from Visual Studio 2003. If you look at your AssemblyInfo file you will likely see the following attributes:

[assembly: AssemblyDelaySign(false)]
[assembly: AssemblyKeyFile("")]
[assembly: AssemblyKeyName("")]

If you remove these three attributes your code will once again compile. It appears that if the compiler see any of these three attributes it thinks that the assembly must be strongly signed.

Had me scratching my head for quite some time.