IIS 7.5 applicationHost.config file is not being updated

Question

I'm currently playing around with the Microsoft.Web.Administration (MWA) namespace in order to adjust our application to configure IIS 7.5 with the new API. I understood that all IIS level changes should be expressed in the following file (I'm on Win2K8-R2):

%WINDIR%\System32\inetsrv\config\applicationHost.config

So, when I use the ServerManager object to commit the configuration changes the file should be updated accordingly.

After adding a new MIME type (programmatic with MWA) I did not see any changes in the applicationHost.config file, but I do see the new MIME type in the IIS manager window and IIS recognizes this MIME type without problems. Even after restating the OS - The config file does not contain the newly added MIME type, but the IIS manager window does list it.

Because my application pools are forced to 32-bit (Enable32BitAppOnWin64 = true), I thought that the related config file should be located under %WINDIR%\SysWOW64\inetsrv\Config, but (if it exists...) - it also does not change after the code commits the updates.

Can someone please explain this? Am I missing something (looking at the wrong file maybe?)? Can someone please shed some light on the SysWOW64\inetsrv\config directory?

This is my code for adding the MIME type:

ServerManager manager = new ServerManager();
ConfigurationElementCollection staticContentCollection = manager
    .GetApplicationHostConfiguration()
    .GetSection("system.webServer/staticContent")
    .GetCollection();

//MIMETypes is a string[] array, each object is {FileExt},{MIMETypeStr}
foreach (string pair in MIMETypes)
{
    string[] mimeProps = pair.Split(',');

    ConfigurationElement mimeTypeEl = staticContentCollection
          .Where(a => 
                   (string)a.Attributes["fileExtension"].Value == mimeProps[0])
          .FirstOrDefault();


    if (mimeTypeEl != null)
    {
        staticContentCollection.Remove(mimeTypeEl);
    }

    ConfigurationElement mimeMapElement = 
                  staticContentCollection.CreateElement("mimeMap");

    mimeMapElement["fileExtension"] = mimeProps[0];
    mimeMapElement["mimeType"] = mimeProps[1];

    staticContentCollection.Add(mimeMapElement);
}

manager.CommitChanges();

//At this point all is working but the config file does not reflect the change

Meed

Answer 1

I just tried your code and it works fine. You are aware that this mime type is being added to the global mime type collection and not to a site?

It also gets added to the end of the <staticContent> list, this list isn't re-sorted when you do ServerManager.CommitChanges().

Also on Windows 2008-R2 the correct location for applicationHost.config is at:

C:\Windows\System32\inetsrv\config

I'm guess you're either using notepad.exe or NotePad2 to open this file (32 bit editors can't open it). Notepad won't reload the file upon a change and NotePad2 needs to be told to display a file change notification (alt-F5), out of the box it won't.

Also try adding something unusual like .xxx, run your update then open the config file and do a search. I guarantee it'll be there.

Update:

Further to your comments below, I'm not sure how you're able to open applicationHost.config using NotePad++ or any 32-bit editor, I certainly can't. Can you download NotePad2 which is a 64-bit editor:

http://www.flos-freeware.ch/notepad2.html

The release candidate works just fine.

On a default install of any 64 bit Windows 2008 or Windows 7 there shouldn't be an applicationHost.config in the C:\Windows\SysWOW64\inetsrv\Config folder. I'm not sure why you'd be seeing one there.

Lugsail

Hi & thanks for the quick reply :-) The MIME type should be added to the <syste.Webserver>/<staticContent> node as a <mimeMap fileExtension=""" mimeType=""/> node. But again... The code is working, I can see the new type in IIS manager (GUI), but the applicationHost.config file is unchanged, that is, does not contain the new <mimeMap ... /> node anywhere. Even adding something unusual like ".xxx,application/BlaBla" is successful but the config file is unchanged. I'm using Notepad++ or the Visual Studio (10) XML editor to view the file (both apps are 32bit). – Meed

I'm sure I'm viewing the right file (C:\Windows\System32\inetsrv\config\applicationHost.config). What do you mean by saying "...this list isn't re-sorted when you do ServerManager.CommitChanges()". Please explain... – Meed

I've checked it again, with an emphasis on the text viewer. If I open the config file with Notepad++ or VS2010 (both 32bit) - The changes are not there. But... If I open the file with the native Notepad application (64bit) the changes are there! Something does not smell OK here... Seems like the FS redirection (msdn.microsoft.com/en-us/library/aa384187(v=vs.85).aspx) or this issue: support.microsoft.com/kb/942589, are somehow not playing very well... Any suggestions for a 64bit text editor? – Meed

Thanks man! NotePad2 seems just fine & working as expected! Cheers :-) – Meed

There's also a hack way of opening up the applicationHost.config file in 32-bit apps by abusing UNC paths. Instead of navigating to the directory on disk, use the UNC path (eg. \\192.168.1.100\C$\Windows\System32\inetsrv\config) – Uhlan

@Uhlan - I never knew about that one. Cheers. – Lugsail

That editing the file using a 64-bit editor instead of a 32-editor is a new level of voodoo. – Christogram

@Kev: The most useful thing I've read all day. Who'd have thought that using a 32-bit app would not open/save correctly. – Whiz

Another way to access this file without using a UNC path, is to use the Sysnative alias: notepad++ %SystemRoot%\Sysnative\inetsrv\config\applicationHost.config (You cannot go to this path with explorer, because it's only visible to 32-bit applications) – Lonnielonny

Answer 2

As a workaround to open and edit the 64-bit IIS configuration files with your favorite 32-bit editor that is 64-bit compatible (i.e. Notepad++), you can create a Windows directory symbolic link which points to C:\Windows\System32\inetsrv\Config. With this method, you are replacing the 32-bit Config directory, located at C:\Windows\SysWOW64\inetsrv\Config to point to the 64-bit version. If, for example, you have an application which requires both 32-bit and 64-bit versions, this method won't work.

For more information, I strongly encourage you to visit this MSDN Blog.

Fen