Visual Studio templates

Visual Studio 2008 sticks a bunch of using statements at the top of any new C# source file. They include System.Collections.Generic and System.Linq. I tend to not use these for my current projects, but instead to use System.Collections.ObjectModel (where Collection<> lives) and System.Xml.Linq (where XElement etc live).

After a little poking around, here's what you do to change the template:

In %ProgramFiles%\Microsoft Visual Studio 9.0\Common7\IDE\ItemTemplates\CSharp\Code\1033\Class.zip

is a template called Class.cs. Edit it to say something like this:

using System;
using System.Collections.ObjectModel;
$if$ ($targetframeworkversion$ == 3.5)using System.Xml.Linq;
$endif$

namespace $rootnamespace$
{
  class $safeitemrootname$
  {
  }
}

Save it back into the zip file and run

devenv.exe /setup

Then restart Visual Studio and all is good.

One caveat: I am not sure exactly what features might get reset by running with the /setup option. It didn't trash my custom font settings at least.

Land of expensive books

Books are expensive in New Zealand. Always have been. Now that we are living here, we have become avid users of the public library, which is probably a Good Thing (R) (TM) anyway.

Over the weekend I decided to spend a gift card at Borders (the same chain as in the US). I had read a good review of Steve Skiena's "The algorithm design manual" -- $75.50 USD on BetterWorld including shipping. That's $100 NZD at the current exchange rate. Shipping from the US usually takes 7-10 days -- USPS doesn't ship by sea any more.

Borders didn't have it but they could special order it for the princely sum of $215 NZD. BetterWorld it is then.

This is completely nuts -- more than double the price of buying it from a US retail source. For items that might involve after sales support (e.g. electronics goods) I could understand paying a small premium. Labor costs in NZ are high after all. But this is a book we're talking about.

XLinq in C#

I have been converting some rather inelegant bits of C# code (stuff I had written, no reflection on anyone else) from the DotNet 2.0 XPathNavigable way of doing things to the DotNet 3.0 Linq way of doing things.

Using XLinq (Linq on XML) is fun. It's a shiny new hammer that you can use for banging in all sorts of nails, but you can get a bit carried away.

In my case, I have been extracting the externalNames (think, fully qualified names) of some XSOL variables and stuffing them in a Collection called variables. MSDN has trivial examples that are more or less like this

IEnumerable externalNames =
from externalName in root.Descendants("externalName")
select (string)externalName;

foreach (string name in externalNames)
{
  variables.Add(name);
}

That all seems simple enough: extract the contents of the descendant elements.

Of course, it can be collapsed to make things a little more elegant without making them more obscure:

foreach (string name in
from externalName in root.Descendants("externalName") select (string)externalName)
{
  variables.Add(name);
}

But then I get to thinking, why not do it all in one go? The result of all that Linq stuff is an IEnumerable. I can't implicitly convert it to a Collection but there is an overload for the constructor for Collection<> that will do the trick:

variables = new Collection(
(from externalName in root.Descendants("externalName") select (string)externalName)
.ToList());

So there you go. You can do it using the new shiny hammer but things are starting to look more complex than is necessary. Thinking about it some more, it really is sufficient to skip all that Linq and say

foreach (XElement externalName in root.Descendants("externalName"))
{
  variables.Add(externalName.Value);
}

This is not to say that XLinq is not a good thing. Clearly it would be wonderful for more complex queries.

Registry on 64 bit Windows

The world is slowly but surely moving to 64 bit but along the way there are a few wrinkles to work out.

At XSOL we develop tools that people use to model their business processes. They can do that as an end in itself e.g. for internal documentation or they can press a button and we produce a custom line of business application for them with a SQL back end etc. We use Python for application extensibiity.

A customer was having trouble getting our installer to run on their 64 bit machine. The installer checks for the presence of Python (which they have to install separately for licensing reasons) by looking in the registry. It was failing to detect that they had Python installed.

It transpires that our code that checked for the presence of Python was in a 32 bit DLL. Windows 2003 64 bit (and Vista 64 bit) does a bit of magic when 32 bit apps look at the registry, like the magic it does about the location of the "documents and settings" folder etc. Long story short, we had to create an entry in the right place just to fool our installer.

On a 32 bit OS we look at

HKEY_LOCAL_MACHINE\SOFTWARE\ActiveState \ActivePython \2.5.1.1

On a 64 bit OS running our 32 bit detection code we think we are looking there but we are actually looking at

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node \ActiveState \ ActivePython\2.5.1.1

There is of course a KB entry about this: http://support.microsoft.com/kb/896459

ASP.Net and localhost

Ah the Monday morning software patch routine. Time for a Windows update that wants a restart. After the restart my dual monitor configuration is toast yet again. By now the process for fixing dual mon is quite familiar: click some options, don't panic about the displays being upside down, restart the machine, then change the orientation for the monitor that wasn't working.

Then on to the next issue: ASP.Net debugging using Visual Studio's Cassini server on Vista. Issue #1, IPv6 problems -- edit C:\Windows\System32\drivers\etc\hosts, add an extra : for the localhost mapping i.e. it should say

127.0.0.1 localhost
:::1 localhost

Then on to the next issue: when I attempt to run the website in VS2008, I see that it has fired up Cassini on some random port but the port that IE thinks it is using is two less, e.g. is Cassini is using 49756, IE thinks we are using port 49754. It's consistently off by two. If I manually correct the port in the address bar in IE it's fine. The solution involves some tweaking of settings in Eset NOD antivirus:

http://forums.asp.net/p/1235447/2267983.aspx

There are some nice screen shots and detailed instructions that I won't bother to reproduce here. Suffice to say that you should pay close attention to putting a cross not a check mark beside devenv.exe.

This fix doesn't require a restart of your machine, but you will of course have to stop any current Cassini session.

Modern ASCII art

I must confess that for the last few years I haven't been paying much attention to the mechanics of web page design. Lately I have been pottering in ASP.Net which has been a lot of fun. I was dimly aware that laying out my page using tables probably wasn't au courant so I have been doing a crash update course on the use of the div tag. No magic there and of course CSS is extremely straight forward.

Sometimes though you come across something done using the current technology that you never would have imagined was even possible. Check out this: a rendering of Homer Simpson done entirely with div tags. If you inspect the underlying source you can see that it's actually ASCII art.