在 ASP.NET 3.5 网站子文件夹下部署 ASP.NET MVC 3 应用程序

发布于 2024-12-27 08:56:10 字数 297 浏览 1 评论 0原文

我有一个在 IIS 7、ASP.NET 3.5 中运行良好的网站。我刚刚在此网站服务器上安装了.NET 4.0。现在,我在该网站中添加了一个带有 Asp.Net 4.0 AppPool 的虚拟目录(是的,我将其转换为应用程序)。当我访问此虚拟目录时,我收到

There is a duplicate 'system.web.extensions/scripting/scriptResourceHandler' section defined

“为什么此虚拟目录应用程序尝试使用根网站的 web.config?”

I have a website in IIS 7, ASP.NET 3.5 which works well. I have just installed .NET 4.0 on this website server. Now, I have added a virtual directory(Yes, I Converted this to Application) with Asp.Net 4.0 AppPool in this website. When I access this Virtual Directory, I get

There is a duplicate 'system.web.extensions/scripting/scriptResourceHandler' section defined

Why this Virtual Directory Application trying to use root website's web.config?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

星軌x 2025-01-03 08:56:10

正如@BNL所说,我引用了网站的答案,

< strong>步骤 1(仅限 IIS 7 或 IIS 7.5)

仅在运行 IIS 7 或 IIS 7.5 的操作系统(包括 Windows Vista、 Windows Server 2008、Windows 7 和 Windows Server 2008 R2。

将父应用程序(运行 ASP.NET 2.0 或 ASP.NET 3.5 的应用程序)的 Web.config 文件中的 configSections 定义移动到 .NET Framework 2.0 的根 Web.config 文件中。 IIS 7 和 IIS 7.5 本机配置系统在合并配置文件层次结构时会扫描 configSections 元素。将 configSections 定义从父 Web 应用程序的 Web.config 文件移动到根 Web.config 文件可以有效地在子 ASP.NET 4 应用程序发生的配置合并过程中隐藏该元素。

在 32 位操作系统或 32 位应用程序池上,ASP.NET 2.0 和 ASP.NET 3.5 的根 Web.config 文件通常位于以下文件夹中:

C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG

在 64 位操作系统或 64 位操作系统上位应用程序池,ASP.NET 2.0 和 ASP.NET 3.5 的根 Web.config 文件通常位于以下文件夹中:

C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG

如果同时运行 32 位和对于 64 位计算机上的 64 位 Web 应用程序,您必须将 configSections 元素向上移动到 32 位和 64 位系统的根 Web.config 文件中。

将 configSections 元素放入根 Web.config 文件中时,将该部分粘贴到配置元素之后。以下示例显示了元素移动完成后根 Web.config 文件的顶部部分应是什么样子。

注意 在以下示例中,为了便于阅读,已将行换行。

<?xml version="1.0" encoding="utf-8"?>
<!-- The root web configuration file -->
<configuration>
  <configSections>
    <sectionGroup name="system.web.extensions"
        type="System.Web.Configuration.SystemWebExtensionsSectionGroup, 
      System.Web.Extensions, Version=3.5.0.0, Culture=neutral,  
      PublicKeyToken=31BF3856AD364E35">

      <sectionGroup name="scripting"
        type="System.Web.Configuration.ScriptingSectionGroup, 
        System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
        PublicKeyToken=31BF3856AD364E35">

        <section name="scriptResourceHandler"
          type="System.Web.Configuration.ScriptingScriptResourceHandlerSection, 
          System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
          PublicKeyToken=31BF3856AD364E35" requirePermission="false"
          allowDefinition="MachineToApplication" />

        <sectionGroup name="webServices"
          type="System.Web.Configuration.ScriptingWebServicesSectionGroup,
          System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
          PublicKeyToken=31BF3856AD364E35">

          <section name="jsonSerialization"
            type="System.Web.Configuration.ScriptingJsonSerializationSection, 
            System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
            PublicKeyToken=31BF3856AD364E35" requirePermission="false"
            allowDefinition="Everywhere" />

          <section name="profileService"
            type="System.Web.Configuration.ScriptingProfileServiceSection, 
            System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
            PublicKeyToken=31BF3856AD364E35" requirePermission="false"
            allowDefinition="MachineToApplication" />
          <section name="authenticationService"
            type="System.Web.Configuration.ScriptingAuthenticationServiceSection, 
          System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
          PublicKeyToken=31BF3856AD364E35" requirePermission="false"
            allowDefinition="MachineToApplication" />

          <section name="roleService"
            type="System.Web.Configuration.ScriptingRoleServiceSection, 
          System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
          PublicKeyToken=31BF3856AD364E35" requirePermission="false"
            allowDefinition="MachineToApplication" />

        </sectionGroup>
      </sectionGroup>
    </sectionGroup>
  </configSections>

步骤 2(所有版本的 IIS)

无论 ASP.NET 4 子 Web 应用程序是在 IIS 6 还是 IIS 7(或 IIS 7.5)上运行,都需要执行此步骤。

在运行 ASP.NET 2 或 ASP.NET 3.5 的父 Web 应用程序的 Web.config 文件中,添加一个位置标记,明确指定(对于 IIS 和 ASP.NET 配置系统)配置条目仅适用于父 Web 应用程序。以下示例显示了要添加的位置元素的语法:

<location path="" inheritInChildApplications="false" >

以下示例显示如何使用位置标记来包装从 appSettings 部分开始到 system.webServer 部分结束的所有配置部分。

<location path="" inheritInChildApplications="false" >

完成步骤 1 和 2 后,子 ASP.NET 4 Web 应用程序将正常启动。

As @BNL said I am quoting the answer from this site,

Step 1 (IIS 7 or IIS 7.5 only)

This step is necessary only on operating systems that run IIS 7 or IIS 7.5, which includes Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2.

Move the configSections definition in the Web.config file of the parent application (the application that runs ASP.NET 2.0 or ASP.NET 3.5) into the root Web.config file for the.NET Framework 2.0. The IIS 7 and IIS 7.5 native configuration system scans the configSections element when it merges the hierarchy of configuration files. Moving the configSections definition from the parent Web application’s Web.config file to the root Web.config file effectively hides the element from the configuration merge process that occurs for the child ASP.NET 4 application.

On a 32-bit operating system or for 32-bit application pools, the root Web.config file for ASP.NET 2.0 and ASP.NET 3.5 is normally located in the following folder:

C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG

On a 64-bit operating system or for 64-bit application pools, the root Web.config file for ASP.NET 2.0 and ASP.NET 3.5 is normally located in the following folder:

C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG

If you run both 32-bit and 64-bit Web applications on a 64-bit computer, you must move the configSections element up into root Web.config files for both the 32-bit and the 64-bit systems.

When you put the configSections element in the root Web.config file, paste the section immediately after the configuration element. The following example shows what the top portion of the root Web.config file should look like when you have finished moving the elements.

Note In the following example, lines have been wrapped for readability.

<?xml version="1.0" encoding="utf-8"?>
<!-- The root web configuration file -->
<configuration>
  <configSections>
    <sectionGroup name="system.web.extensions"
        type="System.Web.Configuration.SystemWebExtensionsSectionGroup, 
      System.Web.Extensions, Version=3.5.0.0, Culture=neutral,  
      PublicKeyToken=31BF3856AD364E35">

      <sectionGroup name="scripting"
        type="System.Web.Configuration.ScriptingSectionGroup, 
        System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
        PublicKeyToken=31BF3856AD364E35">

        <section name="scriptResourceHandler"
          type="System.Web.Configuration.ScriptingScriptResourceHandlerSection, 
          System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
          PublicKeyToken=31BF3856AD364E35" requirePermission="false"
          allowDefinition="MachineToApplication" />

        <sectionGroup name="webServices"
          type="System.Web.Configuration.ScriptingWebServicesSectionGroup,
          System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
          PublicKeyToken=31BF3856AD364E35">

          <section name="jsonSerialization"
            type="System.Web.Configuration.ScriptingJsonSerializationSection, 
            System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
            PublicKeyToken=31BF3856AD364E35" requirePermission="false"
            allowDefinition="Everywhere" />

          <section name="profileService"
            type="System.Web.Configuration.ScriptingProfileServiceSection, 
            System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
            PublicKeyToken=31BF3856AD364E35" requirePermission="false"
            allowDefinition="MachineToApplication" />
          <section name="authenticationService"
            type="System.Web.Configuration.ScriptingAuthenticationServiceSection, 
          System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
          PublicKeyToken=31BF3856AD364E35" requirePermission="false"
            allowDefinition="MachineToApplication" />

          <section name="roleService"
            type="System.Web.Configuration.ScriptingRoleServiceSection, 
          System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
          PublicKeyToken=31BF3856AD364E35" requirePermission="false"
            allowDefinition="MachineToApplication" />

        </sectionGroup>
      </sectionGroup>
    </sectionGroup>
  </configSections>

Step 2 (all versions of IIS)

This step is required whether the ASP.NET 4 child Web application is running on IIS 6 or on IIS 7 (or IIS 7.5).

In the Web.config file of the parent Web application that is running ASP.NET 2 or ASP.NET 3.5, add a location tag that explicitly specifies (for both the IIS and ASP.NET configuration systems) that the configuration entries only apply to the parent Web application. The following example shows the syntax of the location element to add:

<location path="" inheritInChildApplications="false" >

The following example shows how the location tag is used to wrap all configuration sections starting with the appSettings section and ending with system.webServer section.

<location path="" inheritInChildApplications="false" >

When you have completed steps 1 and 2, child ASP.NET 4 Web applications will start without errors.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文