locked
PowerShell Module WebAdministration Uses .NET 2.0 RRS feed

  • Question

  • User-1105639637 posted

    When using the PowerShell IIS module "WebAdministration" with IIS 7.5 to configure Authentication and the website or application's web.config file contains a section(element) that is specific to .NET 4.0, an error is encountered.

    Here is the command to reproduce:

    Import-Module -Name WebAdministration
    Get-WebConfigurationProperty -Filter '/system.webServer/security/authentication/windowsAuthentication' -Name 'enabled' -Location 'MyWebSite' 
    

    Here is the error encountered:

    Filename: \\?\C:\MyApplication\web.config
    Line number: 87
    Error: The configuration section 'routing' cannot be read because it is missing a section declaration
        + CategoryInfo          : NotSpecified: (:) [Get-WebConfigurationProperty], COMException
        + FullyQualifiedErrorId : System.Runtime.InteropServices.COMException,Microsoft.IIs.PowerShell.Provider.GetConfigu
       rationPropertyCommand

    The application's abbreviated web.config XML structure which contains the .NET 4.0 element "routing". NOTE: There is no issue with the IIS application using the .NET 4.0 section "routing" successfully:

    <configuration>
      <system.serviceModel>
        <routing>
        </routing>
      </system.serviceModel>
    </configuration>

    The .NET 2.0 machine.config contents. Observe there is no "routing" section declared (C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG\machine.config)

    <configuration>
      <system.serviceModel>
    
      </system.serviceModel>
    </configuration>

    The .NET 4.0 machine.config contents. Observe the "routing" section is declared (C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config)

    <configuration>
      <configSections>
        <sectionGroup name="system.serviceModel" type="System.ServiceModel.Configuration.ServiceModelSectionGroup, System.ServiceModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
          <section name="routing" type="System.ServiceModel.Routing.Configuration.RoutingSection, System.ServiceModel.Routing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
        </sectionGroup>
      </configSections>
      <system.serviceModel>
        <extensions>
          <behaviorExtensions>
            <add name="routing" type="System.ServiceModel.Routing.Configuration.RoutingExtensionElement, System.ServiceModel.Routing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
          </behaviorExtensions>
        </extensions>
      </system.serviceModel>
    </configuration>

    I also observed that there was a seperate downloadable installer for the WebAdministration module available for IIS 7, but not one for IIS 7.5 (http://www.iis.net/downloads/microsoft/powershell)

    This related blog  post has a similar issue (http://forums.iis.net/t/1176074.aspx). I concur with the original poster "I think the issue is the WebAdministration module loaded machine.config of CLR 2.0", and I do not believe its resolution is accurate. I tried to re-post to this thread but it was locked.

    I assert that the PowerShell IIS 7 module "WebAdministration" loads using the .NET 2.0 machine.config (C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG\machine.config).
    Does anyone know if this is the issue?
    Is there a workaround or is this a bug?

    Windows 2008 R2 SP1
    IIS 7.5

    Tuesday, May 6, 2014 5:20 PM

Answers

  • User690216013 posted

    IIS 7.* was built before .NET 4 was released. Thus, you can see that most of its API is dedicated to .NET 2.0.

    Personally I think the issue you hit is by design, and is very similar to the known issues of ASP.NET 2.0/4.0 side by side (such as http://www.asp.net/whitepapers/aspnet4/breaking-changes#0.1__Toc256770150). 

    Thus, the workaround I can think of, is to add the .NET 4 related configSections to .NET 2 corresponding files, so as to suppress the exceptions.

    You can open a support case via http://support.microsoft.com to further discuss with Microsoft.

    • Marked as answer by Anonymous Tuesday, September 28, 2021 12:00 AM
    Tuesday, May 6, 2014 11:48 PM