I spent a few hours on Friday working on a problem that’s weird enough that I feel it warrants a blog entry. I made a few changes to one of our systems at work recently, and rolled them out Friday morning. This system is a VS 2008 solution with several projects in it. One of the projects is a bunch of web services, both SOAP and REST, that are deployed as a single DLL. I made a minor change to one of the REST services, but didn’t touch the SOAP services. And I made a minor change to a class in what is essentially a data access layer project that is referenced in the web service project, but nothing that should have affected the SOAP services. I’m saying all this to establish that I did not change anything that should have changed the SOAP services at all.
Returning to the data access project: this project was initially auto-generated through some CodeSmith templates, long before I started working for the company. The idea was that every class was implemented as a partial class broken into two files, with one file that contained auto-generated code, and one that could be used to add custom code. Now, some of these classes are used as output for the SOAP services. And those services just use the default XML serialization. (Some of you may see where this is heading.)
So we’re got a class called, let’s say, “Location,” broken into file X and file Y. File X contains properties A, B, and C, and file Y contains properties D, E, and F. Up until Friday, these properties had always been serialized from file X, then file Y, so they appeared in the output as A, B, C, D, E, and F. For some reason, on Friday, the compiler decided to process file Y before file X, and give me an XML document ordered as D, E, F, A, B, C. And, of course, the C# programs we have that actually call these web services don’t like getting their properties out of order. They expect everything to look exactly like the WSDL that was pulled in when they were last deployed. Oh, and most of them don’t have any useful error-handling or logging, and do a lot of their work in a declarative manner, through controls in the .aspx files rather than in code-behind, where I can see what’s going on step-by-step in the debugger. So figuring out what had gone wrong was interesting.
It had never really occurred to me, though I’m sure I read it at some point, that there is no guarantee as to the order in which the C# compiler will process the individual files that make up a partial class. (See this Stack Overflow question for reference.) I think the reason it changed now is that I moved the project from VSS to Mercurial recently, and that change probably caused enough of a disturbance to muck things up a bit.
I think if I had been the one that had implemented this thing in the first place, I would probably have done custom XML serialization, just because I’m a bit of a control freak, so I wouldn’t have ever had this problem.
Well, anyway, the moral of this story is that you shouldn’t assume that, just because a bit of code has been working for years, and you honestly haven’t touched it at all, that nothing can go wrong with it, and that the compiler will always output the same code given the same source code.