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;

C:\MyTests\bin

…and some projects

C:\web\test1

C:\web\test2

C:\winApp\test3

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.

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.

This confused me for a bit, they’ve moved the Network DTC Access dialog from the MSDTC tab to its own node…

Select properties on the above node…