Using Visual Studio 2008 on a 64-bit Computer to edit ApplicationHost.config

Visual Studio 2008 as an XML Editor

Everyone seems to have their own favorite XML editor these days, and there are no shortages of XML editors in the marketplace. The being said, I tend to use Visual Studio 2008 for several reasons, and if you're using Windows notepad or some other editor, here are some of my reasons why you might consider switching:

  • I've already bought a copy of Visual Studio for application development, so I don't need to purchase another utility.
  • I'm already familiar with the Visual Studio interface and features, so I don't need to learn another user interface.
  • Syntactical highlighting - Visual Studio makes it easy to see your XML in a user-friendly set of colors. If you already use Visual Studio for application development, then you're simply sticking to a paradigm that you're already familiar with.
  • Auto-completion - as I create XML elements in Visual Studio I get all of the auto-completion features that you'd expect from an XML editor, which speeds up my configuration editing.
  • Simple validation - Visual Studio lets me know when elements become mismatched or sections are not closed properly.

But one of my personal favorites is change notifications. These are great, because I do some of my work in ApplicationHost.config directly, while other times I'm using AppCmd.exe or the IIS Manager to update my settings. If I leave Visual Studio open, it detects that the configuration file was changed externally and prompts me to reload.

This feature alone has probably saved me more times that I can imagine.

The 32-bit Versus 64-bit Problem

All of the above information leads me to an interesting challenge - what do you do if you have Visual Studio 2008 installed on a 64-bit system? Visual Studio is a 32-bit application, and it runs just fine on a 64-bit system, but unfortunately 32-bit applications cannot open files that are kept in 64-bit-only file paths - and that includes ApplicationHost.config.

Here's why this happens - ApplicationHost.config is physically located in the following 64-bit-only path:

%SystemDrive%\Windows\System32\Inetsrv\config

The problem is, 32-bit applications are "magically" redirected by the operating system to the following 32-bit file path:

%SystemDrive%\Windows\SysWOW64\Inetsrv\config

So what happens is that each 32-bit application thinks that it's in the real System32 folder, so when you try to open ApplicationHost.config using File » Open » File... in Visual Studio, you don't see ApplicationHost.config in the Inetsrv folder. If you attempt to outsmart the system by dragging-and-dropping ApplicationHost.config into Visual Studio from Windows Explorer it doesn't work; you don't get any errors, Visual Studio just sits there and stares back at you.

NTFS Symbolic Links to the Rescue

NTFS has had junction points around for some time now, but NTFS has added symbolic links starting with Windows Vista and Windows Server 2008. These are not Windows shortcuts - symbolic links appear to applications as actual files and folders. The great thing is - you can create a symbolic link from a 32-bit-only path to a 64-bit only-path, which is how you can get around the problem and use Visual Studio to edit ApplicationHost.config directly on a 64-bit system.

The command that makes this possible is Mklink.exe, and if you enter that command at a command prompt you get the following help information:

CMD>mklink /?
Creates a symbolic link.

MKLINK [[/D] | [/H] | [/J]] Link Target

        /D      Creates a directory symbolic link.  Default is a file
                symbolic link.
        /H      Creates a hard link instead of a symbolic link.
        /J      Creates a Directory Junction.
        Link    specifies the new symbolic link name.
        Target  specifies the path (relative or absolute) that the new link
                refers to.
CMD>

Here's how you use this command on a 64-bit system:

First of all, you need to open a 64-bit command prompt, because the steps won't work from a 32-bit command prompt. An easy way to find out whether you have a 64-bit or 32-bit command prompt is to use the following command:

CMD>set | find "PROCESSOR_ARCHITECTURE"

If the above command returns "PROCESSOR_ARCHITECTURE=x86", then you're using a 32-bit command prompt and you will need to close the command prompt and open a 64-bit command prompt. If you see something like "PROCESSOR_ARCHITECTURE=AMD64" then you're using a 64-bit command prompt and everything should be fine.

Once you have a 64-bit command prompt, type the following commands:

CMD>cd /d "%SystemDrive%\Windows\SysWOW64\inetsrv"

CMD>move Config Config.OLD

CMD>mklink /d Config "%SystemDrive%\Windows\System32\inetsrv\Config"

These commands perform the following actions:

  • Change the command prompt working directory to the 32-bit folder for IIS.
  • Rename the existing (and typically empty) 32-bit IIS configuration folder. (See note below.)
  • Create a directory symbolic link that replaces the 32-bit IIS configuration folder and points to the 64-bit IIS configuration folder. (See note below.)

Important Note: Something that you should consider - if your 32-bit IIS configuration folder is not empty, you will need to find out what is in that folder and whether it needs to be copied to the 64-bit folder. For example, the FTP 7 service for IIS 7 adds a schema file to the 32-bit configuration path, but it's just a copy of the file that resides in the 64-bit path, so it does not need to be copied. If an application exists that requires different files for 64-bit and 32-bit operation, then you cannot use this workaround.

Once you have completed the above commands, you can check your directory listing from a 64-bit command prompt to make sure that your symbolic link has been created; you should see something like the following:

CMD>cd /d "%SystemDrive%\Windows\SysWOW64\inetsrv"

CMD>dir /ad

Volume in drive C has no label.
Volume Serial Number is 426F-624D

Directory of C:\Windows\SysWOW64\inetsrv

10/20/2008 03:52 PM <DIR> .
10/20/2008 03:52 PM <DIR> ..
10/20/2008 03:52 PM <SYMLINKD> Config [C:\Windows\System32\inetsrv\Config]
04/18/2008 04:24 PM <DIR> Config.OLD
04/18/2008 02:55 PM <DIR> en
04/18/2008 03:47 PM <DIR> en-US
              0 File(s) 0 bytes
              6 Dir(s) 51,247,341,568 bytes free

CMD>

Notice the <SYMLINKD> entry in the directory listing - this shows that a symbolic link was created, and the target path is indicated in the directory listing next to the name of the symbolic link.

You can now open ApplicationHost.config in Visual Studio 2008 on your 64-bit system with no problems, and still have features like change notifications.

Closing Thoughts

If you look at the help output for Mklink.exe, you'll notice that you can also create symbolic links for files, not just directories. This leads to the question: why didn't I just create a file symbolic link for ApplicationHost.config instead of the folder symbolic link for the entire Config directory?

The answer goes back to one of my favorite features: change notifications, which are implemented at the folder-level, not the file-level. So you can create a file symbolic link for ApplicationHost.config and that will allow you to open the file, but you won't receive any change notifications, so if you update your settings using AppCmd.exe or IIS Manager, Visual Studio will be unaware of any changes and the next time you save ApplicationHost.config from Visual Studio you will overwrite your changes that were made using AppCmd.exe or IIS Manager. Needless to say - this is a bad thing, so you should always use the directory symbolic link.

2 Comments

Comments have been disabled for this content.