So a unit test broke inexplicably when I put it up to the CruiseControl server, and it didn't work on a collegue's machine either. It boiled down to the fact that a System.Web.UI.WebControls.Image with no AlternateText doesn't render an ALT attribute AT ALL on my collegue's machine, whereas on mine I get an empty ALT attribute.
<img src="" id="myList" alt="" border="0" />
<img src="" id="myList" border="0" />
Fair enough you might say, but we've both got the same version of System.Web.dll: 1.0.5000.0 from .Net v1.1.4322
Or have we?
Well obviously not, or we wouldn't be getting different Render() output. A quick squiz with Reflector indicates my assembly has internal version number f6153c24-4a3b-4f01-85cf-33d0fb852aea and size 1257472 bytes, and my collegue has e0b58e50-995f-4d8b-9d21-af7678f61626 with size 1245184 bytes. Drilling in a little futher with the disassembler finds the culprit: an extra condition in the latter that only writes the ALT tag out if AlternateText.Length > 0.
What's the moral? I don't know, but if you can't trust people to increment their version numbers when they release new versions then god help us all.
(As an aside, because assemblies in the GAC are tracked on a version number + public key basis, these two DIFFERENT assemblies are considered identical. This is presumably why MS chose not to increment the version number: because it was such a tiny weeny change. Enough of a change, however, to be noticable, and to break my (deliberately brittle) code. Bastards. Increment the version and use an Publisher Policy like you're meant to...)
Summary: Even if you think you know what you're doing, it is not safe to store anything in a ThreadStatic member, CallContext or Threa...
I love PowerShell, and use it for pretty much everything that I’m not forced to compile. As a result I’ve got fairly competent, and people h...
Look, it’s really not that hard. Programs are still in the same place, in %ProgramFiles%, unless you need the 32 bit version, which is in...