JavaScript doesn't have built-in functions to escape or unescape HTML, which may come in handy for certain DOM manipulations or AJAX scripting.  Here are the custom functions I wrote to handle these tasks.  I've tested the implementation with both IE and Firefox.

If you subtract one timestamp from another in Oracle, the result is an interval type.  This is similar to how subtracting a DateTime from another in .NET yields a TimeSpan.  Unfortunately, unlike .NET, Oracle provides no simple equivalent to TimeSpan.TotalSeconds.

Here's the SQL to accomplish it.  Note that fractions of a second are included in the result.

You can't set the next value of a sequence directly in Oracle; you have to drop and recreate the sequence.  Here's a way to do it if you need to set the next value to the largest value in a particular column plus 1:

If you've run a unit test in Visual Studio 2008 that utilizes database connectivity, you may have seen this error when creating a connection object:

Instance names used for writing to custom counters must be 127 characters or less.

The problem crops up when you're running the test within a directory structure with a fairly long name, i.e. you're organizing your code well and giving your projects descriptive names.  Well, this error is punishment for being organized.

There are several Microsoft bug reports on the issue.  One has been ignored, the other closed.

• http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=95049
• http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=176361

There are posts on the web with some workarounds, but none worked for me, perhaps because I'm using Visual Studio 2008?  No matter what I tweaked in .testrunconfig I was still getting the error.  The other approach--shortening the pathname--was really a non-starter.  I wasn't going to compromize well-thought-out organization to get around a Microsoft bug.

So I took a peek at the source of the problem as hinted by the call stack when the error appeared.  It's a method in the internal DbConnectionPoolCounters class in the System.Data.ProviderBase assembly.  Here's the code:

The instance name of the performance counter is being built, in part, from the name of the AppDomain.  When running tests in Visual Studio, this name can be very, very long, especially if your project's home has a long pathname.

The workaround I pursued, then, is to shorten the name of the app domain.  While AppDomain.FriendlyName is a read-only property, and there's no private field of the AppDomain class to change it, there is a private extern method of AppDomain called nSetupFriendlyName.  And, like magic, if you invoke this method and give the app domain a shorter name, problem solved!

Here's the workaround, utilizing a little reflection magic:

When you use the tag, such as on a master page, the HtmlHead control does the rendering work. The results are pretty dreadful; spacing is pretty screwy for one thing. But that's something I can live with.

One thing I can't live with, however, is third party components like DevExpress adding bogus (and redundant!) stylesheet links within the head tag! I wanted to take control of that tag to filter out these tags, but found HtmlHead to be a sealed class. I can't tell you how many times I've tried to correct bad behavior through the well-established OO practice of inheritance only to find a "sealed" wall in my way. Personally, I think that keyword needs to go! But, alas, in this case there is a way to get around the constraint.

I didn't realize this until today, but ASP.NET has a mechanism for overriding how a control renders its content, even if that control is sealed. The magic is in browser adapters. I learned all about it here:

• ASP.NET "Head" Rendering Issues!
• ASP.NET: Override HtmlHead Rendering with ControlAdapters

Well, here's a new one.  Xenocode is offering software virtualization (as opposed to hardware virtualization).  You can use it to render that product installer obsolete.  Bundle all your DLLs, registry changes, and other program files into one self-sufficient EXE.  Pretty cool!

If you add the [TestMethod] attribute to methods in a regular class library, they won't show up in the test view or test editor.  You may see a message "no tests are loaded."  This happens because Visual Studio doesn't look for the attribute in projects that don't have special "I am a test" markings.  If you create a test project from scratch and add the code the problem will go away, but if you've spent time customizing a project, its references, etc., fear not; you don't need to start over.  Edit the .csproj (or .vbproj) file manually and add the following XML as a child of the first <PropertyGroup> element that appears:

Playing around with WiX 3.0, candle.exe started emitting a weird message and failing:

   WixUIExtension.dll could not be loaded

I fixed this by editing the WiX project file by hand and changing the HintPath to remove the ".dll" extension, i.e. instead of this:

   <HintPath>../path/WixUIExtension.dll</HintPath>

Use this:

   <HintPath>../path/WixUIExtension</HintPath>

Setting the DefaultButton property on a form to an ImageButton, LinkButton, or Button with UseSubmitBehavior=false doesn't work on Firefox because the ASP.NET code hooking the Enter key on form submit looks for a "click" method on the button that Firefox does not support.

If you give your button a name attribute, say name='DefaultButton' for example, then throw the following JavaScript in a file that's included on all pages, it'll work.  The trick is to define the click method on Firefox's behalf.

Update on 6/9/08:

That fix apparently doesn't work completely, as when you hit <Enter> in a textarea the form is submitted.  That's a critical flaw.  I didn't want to wholesale replace ASP.NET's WebForm_FireDefaultButton method, but, c'mon, there's only so much tolerance anyone can have for hunting down and working around other people's bugs. 

So, here's a tweaked version of the function that fixes default button handling and works across browsers.  In order to use this patched function, you need to define it *after* all other JavaScript files and also after <ajaxToolkit:ToolkitScriptManager /> if you happen to be using it.

If you've done any dynamic manipulation of web pages, especially with AJAX or any other kind of web magic in the mix, you've run into IE's dreaded "Operation Aborted" error.

Here are some official comments on the issue:

• http://support.microsoft.com/kb/927917/en-us 
• http://blogs.msdn.com/ie/archive/2008/04/23/what-happened-to-operation-aborted.aspx

The blog post says that if you aren't meeting all 3 conditions, you're OK.  In my case, I believe I wasn't meeting the 3 conditions, and yet the problem persisted.  It was very hard to reproduce, too.  I had to have the offending website in the "Internet Zone" and experience some network lag to make it happen.

In the end, I found that if I replaced this line:

   document.body.appendChild(element);

With this one:

   document.body.insertAdjacentElement('afterBegin', element);

Everything worked fine.  Of course, this trick works only if you're inserting a node whose position isn't important, e.g. it's a div you're going to give an absolute position anyway.

Along the way I had tried wrapping the appendChild calls in a try/catch block, but unfortunatley the append would work fine, and then IE would complain with "Operation Aborted" only after the JavaScript finished.  I was hoping for a global exception handler to trap the problem, but fortunately insertAdjacentElement fixes the issue!