ADSI, IIS and Windows 7+

Time for another one of my, please-don’t-forget-this-again posts.

I was running some code today that was calling the ADSI (Active Directory Service Interfaces)IIS://LocalHost/W3SVC. However I was getting access denied. After trying every admin user on this earthly realm I decided that access denied was a red-herring. I then realised that ADSI is an IIS6 only feature and not part of IIS7. Once I enabled the IIS6 compatibility features the code started working again.

Sharing a single bin folder across multiple sites

During development it’s often useful to have multiple sites (and other app domains) using the same bin folder even if they are located in different locations. My preferred mechanism is to use a directory junction.

E.g. you have a bin folder;


…and some projects




Open command prompt and navigate to each of the project folders and issue the following command (make sure there isn’t already a bin folder in those locations);

mklink /J bin C:\MyTests\bin

…it should display;

Junction created for bin <<===>> C:\web\test1\bin

…there, when the app domains run they’ll look (probe) for the code in the locale bin folder which in reality lives at C:\MyTests\bin. So you can now update a DLL once it will be reflected in all your tests locations. Obviously this my increase your file locking headache but you takes your choice.

ActiveX cannot create object on old site hosted on Win7 64bit

My colleague and I ran into a problem today where an old ASP site had problems creating old VB6 components. So as not to forget what to do;

In Win64 the registry is conceptually broken into two versions, one for 64 and one for 32 (or Wow). So when you register a 32bit COM component then it lives under HK_CLASSES_ROOT\Wow6432Node rather than just HK_CLASSES_ROOT. This is important because when we were profiled the registry access would could see that the call to create the object was failing because it couldn’t locate the prog id in CLASSES_ROOT. The reason it was looking there was the web site was running as a 64bit process and therefore was looking in the Wow section. The answer to the problem was hidden away in the Advanced Settings of site’s Application Pool in IIS. By turning on ‘Enable 32bit applications’ the OS was able to redirect the registry requests to the correct location and the object was successfully created.