Microsoft.Web.Administration.ServerManager looking in wrong directory for IISExpress applicationHost.config

Question

I have a strange problem when trying to get the application pools on the current machine. It seems that when IISExpress is installed, the Microsoft code wants to check IISExpress in addition to the full IIS. IISExpress uses separate applicationHost files per user. I'm not sure whether this call will require it to check all of those, or just those for the current user. Regardless, it's not finding the one it's looking for in the 'C:\Windows\system32\config\systemprofile\' directory. It should be going to %userprofile% or 'C:\Users\Administrator\' for the user that the application pool that this code is executing under is running as.

Does anyone perhaps know how this systemprofile directory might be coming from?

Exception:-
System.IO.DirectoryNotFoundException: Filename: \\?\C:\Windows\system32\config\systemprofile\Documents\IISExpress\config\applicationHost.config
Error: Cannot read configuration file


   at Microsoft.Web.Administration.Interop.AppHostWritableAdminManager.GetAdminSection(String bstrSectionName, String bstrSectionPath)
   at Microsoft.Web.Administration.Configuration.GetSectionInternal(ConfigurationSection section, String sectionPath, String locationPath)
   at Microsoft.Web.Administration.ServerManager.get_ApplicationPoolsSection()
   at Microsoft.Web.Administration.ServerManager.get_ApplicationPools()
   at CustomCode.Classes.IIsApplicationPool.GetApplicationPool(String iisWebSitePath, String poolName)

Answer 1

I highly recommend to stop using the local reference to Microsoft.Web.Administration that gets shipped with IIS (even if it's in the GAC). This is because it has a very specific version number (i.e. 7.0.0.0) and this version might change in a future version of Windows and it will hurt.

Instead, checkout the nuget package: Microsoft.Web.Administration (https://www.nuget.org/packages/Microsoft.Web.Administration). This basically makes it so you can have a private deployment of your IIS dependencies.

Answer 2

If the application, in which you are using Microsoft.Web.Administration to check for app-pools, is running on IISExpress, it will always fallback to Microsoft.Web.Administration version 7.9.0.0 due to an assemblyredirect in the aspnet.config in the IIS express.

See C:\Program Files (x86)\IIS Express\config\templates\PersonalWebServer\aspnet.config Here is the problem in the config:

<dependentAssembly>
  <assemblyIdentity name="Microsoft.Web.Administration"
                    publicKeyToken="31bf3856ad364e35"
                    culture="neutral" />
  <bindingRedirect oldVersion="7.0.0.0"
                   newVersion="7.9.0.0" />
  <codeBase version="7.9.0.0" 
            href="FILE://%FalconBin%/Microsoft.Web.Administration.dll" />
</dependentAssembly>

Make sure you are running the application in either the full IIS or on the Visual Studio Development Server.

Alternativly you could try and remove the assembly redirect, but i have not tried this, and this might cause problems in other places. We must assume that the IIS Express team made the redirect for some reason (other than convenience) :-)

Answer 3

I already know the answer is old but have you tried specifying a different version of the dll?

A picture is worth in thousand words:

Answer 4

How are you trying to get the application pools? Are you using MWH (Microsoft.Web.Administration) APIs?

1. Full IIS ships with Microsoft.Web.Administration.dll (version 7.0.0.0).
2. IIS Express ships with a different version of Microsoft.Web.Administration.dll (version 7.9.0.0).

It seems full IIS is trying to use IIS Express specific assembly. I am not sure how you ended up in this state, but you can un-install IIS Express and see if this problem still occurs.

Edit:

Why do you want to use Microsoft.Web.Administration (MWA) version 7.9.0.0 in your web application? It is shipped with IIS Express 7.5 to work with per user applicationhost.config file ONLY and this does not use/work with inbox/full IIS configuration file that is located at \windows\system32\inetsrv\config\appliationhost.config.

In your case, web application running under full IIS is running with system identity and therefore MWA 7.9.0.0 is trying to load config file from 'C:\Windows\system32\config\systemprofile' directory.

Answer 5

I've just recently ran into this issue. After reading quite a few posts, this was the closest one at giving me any idea as to what was going on. While I don't necessarily have a solution to the conflict between the two versions (7.0.0.0 and 7.9.0.0) when running within the VS IDE, after a few hours struggling with it, I did find a of quirky trick you can do to work around the IDE's auto-redirection.

In the example of:

Developing an application that's referencing Microsoft.Web.Administration.dll (7.0.0.0) from the inetsrv directory and attempting to do any of the following and trying to connect properly access the application pool definitions of the real IIS, not IIS Express, with not installed. When running the compiled code outside the IDE, it always works correctly regardless of how it's specified.

• ServerManager sm = new ServerManager();
• sm.OpenRemote("localhost");
• sm.OpenRemote("MYPC"); // Presuming you local machine's name is MYPC

These all trigger VS to redirect the reference from the 7.0.0.0 DLL to the 7.9.0.0, which causes the retrieval of incorrect sites or COM exceptions to occurs.

The quirk I found was to always use the OpenRemote(), even though trying to open the local IIS and specify "localhost" or "MYPC" as either "LocalHost" or "MyPc" (i.e. any combination of mixed case so that it is not an exact case-sensitive match to "localhost" (all lower case) or the local machine name.

This quirk may not be specific to all VS versions. I'm currently using VS Professional 2017 (15.9.11).

As I stated, it does fix the redirect, but it definitely help while debugging.

Answer 6

I found mapping the "TeamConfig folder" locally to my development machine helped resolved this issue for me.