Cannot open IIS 7 applicationHost.config in 64-bit Windows with 32-bit text editor

icelava — Sat, 21 Feb 2009 08:34:29 GMT

Every once in awhile, the very act of deviating from the norm to use a *gasp* 64-bit operating system meets with heavenly punishment. So much so that the most rudimentary tasks of opening a text file in a text editor is met with disapproval. I have already encountered this a few times ever since I installed x64 Windows Vista onto my home's main workstation; trying to work with IIS 7.0's new array of configuration files were a hassle. They are right there happily living in Windows Explorer. Opening them with Notepad is all fine and dandy. Like any normal operation should. But Visual Studio 2005 or 2008, or other Notepad replacements for the matter, fail mightily in their attempts to open those config files sitting innocently at C:\windows\system32\inetsrv\config. They consistently report being unable to find those files. They are right there, dammit! Are you blind?

Except, they aren't as "innocent" as one may think they are.

The problem with x64 Windows is certain paths are designated as 64-bit paths, and a 32-bit process, like Visual Studio, is being redirected by Windows to the 32-bit path at C:\windows\SysWOW64 whenever C:\windows\system32 is referenced. The 32-bit process thinks it is looking at C:\windows\system32\inetsrv\config when it has been given C:\windows\SysWOW64\inetsrv\config; which indeed contain none of those configuration files we are after.

It sure sucked using Notepad to edit those files. I want all the sugary goodness of Visual Studio!

Luckily, Robert McMurray came along more than a year later to explain what needs to be done in order to "double trick" 32-bit processes back into the original config directory. To summarise the steps in case the knowledge is lost on the other side, open a 64-bit command prompt and execute the following commands

cd /d "%systemdrive%\windows\syswow64\inetsrv"

move config configx86

MKLINK /d Config "%systemdrive%\windows\system32\inetsrv\Config"

It should report symbolic link created for Config <<===>> C:\windows\system32\inetsrv\Config

This effectively renames the 32-bit config directory so a symbolic link of that name can take its place to redirect back to the 64-bit path which we are really interested in.

Why do WSE 3.0 projects in x64 Windows Vista generate SoapHttpClientProtocol instead of WebServicesClientProtocol?

icelava — Thu, 15 Jan 2009 07:24:03 GMT

In effort to upgrade my certification to MCPD-EA status, I have been retrograding to older frameworks I never had the chance to work on in the past three years. That means putting down that shiny WCF book and dusting off the WSE 3.0 MSDN documentation.

One of the IDE-incorporated features for WSE - which was long present in Visual Studio .NET 2003 - is to get Visual Studio 2005 to generate service proxies based on the Microsoft.Web.Services3.WebServicesClientProtocol class when the project is WSE-enabled. This class provides the base for all the tasty WSE functionality. However, on my main workstation, I consistently witness Visual Studio generating the stock SoapHttpClientProtocol. Manually editting the inheritance to WebServicesClientProtocol is a mere ephemeral accomplishment, since every attempt to Update Web Reference would just result in Visual Studio running the regular wsdl.exe generator.

But it sure worked fine on a laptop I have. The only major difference is the laptop is x86 Windows Vista. My main desktop workstation is x64 Windows Vista. That cannot be the problem, correct? Why, of course it is.

Straight after the launch of .NET Framework 2.0, Microsoft was visibily eager to concentrate on WCF (and .NET Framework 3.0 overall). That was a time when very few developers were even close to hitting the 4GB limit to realise they had to move on to x64 operating systems. Even as of now there are still not enough developers making the switch into 64-bit territory. I can see just how "much" attention WSE 3.0 got from an x64 perspective. Casting nets across various communities yield practically zero experience on what's happening here. It certainly took long enough for me to alter my choices in words to finally dig out the truth.

The WSE 3.0 installer fails to alter Visual Studio 2005's config file C:\Program Files (x86)\Microsoft Visual Studio 8\Common7\IDE\devenv.exe.config with the following entry.

Plug that in, and Visual Studio wakes up from its trance to realise there is a better world out there.

Search results matching tags '64-bit development' and 'visual studio'

Cannot open IIS 7 applicationHost.config in 64-bit Windows with 32-bit text editor

Why do WSE 3.0 projects in x64 Windows Vista generate SoapHttpClientProtocol instead of WebServicesClientProtocol?