piers7 - Professional Profile

http://piers7.blogspot.com/[^]

Have absolutely no idea how I managed it, but all of a sudden Visual Studio 2003 thought all my projects were Windows Applications. The .csproj files were still fine. When the solution loaded a shed load of errors like

"Load of property 'AllowUnsafeBlocks' failed."
"Load of property 'ApplicationIcon' failed."
"Load of property 'AssemblyKeyContainerName' failed."

and so on appear in the Task List.

I eventually found a solution on a SAP forum (I have never had SAP installed on this, or any other, PC) - re-register the C# project DLL

regsvr32 "C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\vcpackages\csproj.dll"

regasm "C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\IDE\PublicAssemblies\VSLangProj.dll"

devenv /resetskippkgs

(from https://www.sdn.sap.com/sdn/collaboration.sdn?contenttype=url&content=https%3A//forums.sdn.sap.com/thread.jspa%3FthreadID%3D12483%26tstart%3D0
)

Thanks SAP. Hope this guy worked it out too...

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.

ie
<img id="myList" alt="" border="0" />
vs
<img 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...)

In IE6 (and probably others), elements nested within a scrolling container (one with overflowY=auto) act as if they're in an absolutely positioned element - ie you need to account for the container when you're setting element.style.top (so you can't - say - just sum all the offsetY's from there to the document root and add/subtract some delta value for a relative-absolute position).
(Every time I (or someone I've worked with) has tried to do something clever in DHTML it's turned round and bit them on the arse. Clearly with the demise of NS4.x things are looking up, but oh-so-slowly)

When setting registry access rights for your encrypted connection strings (you know, the ones you created with ASPNET_SETREG) don't forget to add the new IIS_WPG group if you're deploying to IIS6, since your app's probably not running as ASPNET user any more...

Turns out that VSS 6 (even 6d) has a subtle bug in it's command-line syntax (ss.exe), such that it ignores the AM/PM indicator on the 'from' part of a date range. This plays silly buggers with CruiseControl, unless you set the 24Hr clock format on whatever profile user CruiseControl runs as.

They were, what, like *eight*?

^piers7 - Professional Profile

Summary

Reputation

Privileges