<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="http://icelava.net/utility/FeedStylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Search results matching tags '64-bit development' and 'Windows 2008'</title><link>http://icelava.net/search/SearchResults.aspx?o=DateDescending&amp;tag=64-bit+development,Windows+2008&amp;orTags=0</link><description>Search results matching tags '64-bit development' and 'Windows 2008'</description><dc:language>en-US</dc:language><generator>CommunityServer 2.1 SP1 (Build: 61019.2)</generator><item><title>Cannot open IIS 7 applicationHost.config in 64-bit Windows with 32-bit text editor</title><link>http://icelava.net/forums/post/5391.aspx</link><pubDate>Sat, 21 Feb 2009 08:34:29 GMT</pubDate><guid isPermaLink="false">b5ede4db-7277-4f66-971e-849c7a9a2fd5:5391</guid><dc:creator>icelava</dc:creator><description>&lt;P&gt;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 &lt;EM&gt;opening a text file in a text editor&lt;/EM&gt; is met with disapproval. I have already encountered this a few times&amp;nbsp;ever since I installed x64 Windows Vista onto my &lt;A href="http://icelava.net/mycomputers.aspx#DIABLO"&gt;home's main workstation&lt;/A&gt;; trying to work with IIS 7.0's new array of configuration files were a hassle.&amp;nbsp;They are right there&amp;nbsp;happily living in Windows Explorer.&amp;nbsp;Opening them with Notepad is all fine and dandy. &lt;EM&gt;Like any normal operation should&lt;/EM&gt;. 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 &lt;EM&gt;blind&lt;/EM&gt;?&lt;/P&gt;
&lt;P&gt;Except, they aren't as "innocent" as one may think they are.&lt;/P&gt;
&lt;P&gt;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.&lt;/P&gt;
&lt;P&gt;It sure sucked using Notepad to edit those files. I want all the sugary goodness of Visual Studio!&lt;/P&gt;
&lt;P&gt;&lt;IMG src="http://farm4.static.flickr.com/3348/3296343785_c9390e73e7_o.jpg"&gt;&lt;/P&gt;
&lt;P&gt;Luckily, Robert McMurray came along&amp;nbsp;more than&amp;nbsp;a year later to explain &lt;A href="http://blogs.msdn.com/robert_mcmurray/archive/2008/10/27/using-visual-studio-2008-on-a-64-bit-computer-to-edit-applicationhost-config.aspx"&gt;what needs to be done in order to "double trick" 32-bit processes back into the original config directory&lt;/A&gt;. 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&lt;/P&gt;
&lt;P&gt;&lt;FONT face="courier new,courier"&gt;cd /d "%systemdrive%\windows\syswow64\inetsrv"&lt;/FONT&gt;&lt;/P&gt;
&lt;P&gt;&lt;FONT face="courier new,courier"&gt;move config configx86&lt;/FONT&gt;&lt;/P&gt;
&lt;P&gt;&lt;FONT face="courier new,courier"&gt;MKLINK&amp;nbsp;/d Config "%systemdrive%\windows\system32\inetsrv\Config"&lt;/FONT&gt;&lt;/P&gt;
&lt;P&gt;It should report &lt;FONT face="courier new,courier"&gt;symbolic link created for Config &amp;lt;&amp;lt;===&amp;gt;&amp;gt; C:\windows\system32\inetsrv\Config&lt;/FONT&gt;&lt;/P&gt;
&lt;P&gt;This effectively&amp;nbsp;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.&lt;/P&gt;</description></item></channel></rss>