ASP.NET：从.NET Framework 3.5迁移至4.5后，使用根相对路径（波浪号~）的Response.Redirect()出现路径子文件夹重复问题

Let's break down what's happening here and how to fix it—your expectation that ~ should resolve to the application root is totally correct, so this is definitely a configuration or migration quirk causing the problem.

Possible Root Causes #

First, let's rule out the most likely culprits:

1. Missing or Incorrect targetFramework in web.config #

When migrating to .NET 4.5, if your <httpRuntime> node doesn't explicitly set targetFramework="4.5", ASP.NET might fall back to a compatibility mode that can break path resolution in classic pipeline mode.

Check your root web.config for this line:

<system.web>
  <!-- Make sure this is present and set to 4.5 -->
  <httpRuntime targetFramework="4.5" />
</system.web>

Omitting this can lead to inconsistent behavior between .NET versions, especially with ~ path parsing.

2. Accidental Application Registration for Subfolder #

Even though you said the subfolder isn't registered as an independent app, it's easy for this to happen during migration (either in IIS or IIS Express). If SubfolderInWebApp is mistakenly marked as an application, ~ will resolve to that subfolder's root instead of the main app root, causing the duplicate path.

• IIS Express (Local Dev): In Visual Studio, right-click your project → Properties → Web. Check the "Project URL" field—it should point to http://localhost:[port]/WebAppRoot, not http://localhost:[port]/WebAppRoot/SubfolderInWebApp.
• IIS (Test Env): Open IIS Manager, navigate to your site. Right-click SubfolderInWebApp—if you see "Remove Application" instead of "Convert to Application", it's registered as an app. Click "Remove Application" to revert it to a regular folder.

3. Incorrect Request.ApplicationPath Value #

The ~ resolver relies on Request.ApplicationPath to determine the app root. If this value is wrong, every ~ path will be parsed incorrectly. Add a quick debug line in Page1.aspx.cs to check:

protected void Page_Load(object sender, EventArgs e)
{
    // Add this before your Redirect call to verify
    Response.Write($"Application Path: {Request.ApplicationPath}<br>");
    Response.Write($"Server.MapPath(~): {Server.MapPath("~")}<br>");
    
    // Your original redirect code
    Response.Redirect("~/SubfolderInWebApp/Page2.aspx", false);
}

• In your local dev env, Request.ApplicationPath should be /WebAppRoot (or just / if it's the root site).
• In test env, it should be /WebAppRoot.
  If it shows /WebAppRoot/SubfolderInWebApp, that confirms the subfolder is registered as an app (fix step 2).

4. Inherited Configuration from Subfolder web.config #

If SubfolderInWebApp has its own web.config file, check for settings that might override path resolution. Look for nodes like <virtualDirectory> or any custom appSettings related to paths that could interfere with the app root calculation.

Fixes to Try #

1. Explicitly Resolve the Path First #

Instead of letting Response.Redirect parse the ~ path, use ResolveUrl to explicitly resolve it to an absolute path first. This bypasses any potential quirks in how Response.Redirect handles ~ in .NET 4.5 classic mode:

string resolvedPath = ResolveUrl("~/SubfolderInWebApp/Page2.aspx");
Response.Redirect(resolvedPath, false);

This should work consistently across both environments, and keeps your ~ path usage intact.

2. Verify Application Pool Settings #

Double-check your application pool settings:

• Ensure the pool uses .NET CLR Version v4.0.30319 (you already have this, but confirm it's not set to "No Managed Code").
• Classic mode is correct (since your app was built for .NET 3.5, which uses classic mode by default), but make sure there are no custom pipeline modules overriding path resolution.

Your Expectation is Correct #

To confirm: Your assumption that ~ should resolve to the application root is 100% accurate in ASP.NET. The fact that this worked in .NET 3.5 and broke in 4.5 means there's a misconfiguration, not a mistake in your understanding of ~ paths.

内容的提问来源于stack exchange，提问作者Marc M