~ Пути разрешаются по-разному после обновления до ASP.NET 4 - PullRequest
Новая
       43

~ Пути разрешаются по-разному после обновления до ASP.NET 4

2 голосов
/ 12 октября 2011

Мы обновляем большую систему до ASP.NET 4, и мы обнаружили странную проблему с тем, как пути, начинающиеся с ~, решаются для некоторых наших запросов Ajax. Наши Ajax-запросы используют Server.Execute, а выполняемые ими страницы имеют пути, начинающиеся с ~. Однако в ASP.NET 4 кажется, что этот путь разрешается неправильно, обрабатывая «MyService.aspx / MyMethod» так, как если бы MyService.aspx был папкой. Это отличается от ASP.NET 3.5.

Я создал небольшой образец, чтобы показать проблему.

Мне удалось воспроизвести проблему в небольшом примере:

~ / Default.aspx 

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="WebApplication1._Default" %>
<html>
<head runat="server">
    <script type="text/javascript" src="https://www.google.com/jsapi"></script>
    <script type="text/javascript">
        google.load("jquery", "1.6.4");
    </script>
</head>
<body>

<script type="text/javascript">
    $(function () {
        $.ajax({
            type: "POST",
            url: "WebService1.asmx/HelloWorld",
            success: function (msg) {
                alert(msg.text);
            }
        });
    });
</script>

</body>
</html>

WebService1.asmx.cs 

public class WebService1 : System.Web.Services.WebService
{
    [WebMethod]
    public string HelloWorld()
    {
        var tw = new StringWriter();
        tw.WriteLine("VirtualPathUtility.ToAbsolute(\"~/Images/Blah.png\"): " + VirtualPathUtility.ToAbsolute("~/Images/Blah.png"));
        tw.WriteLine("VirtualPathUtility.ToAppRelative(\"~/Images/Blah.png\"): " + VirtualPathUtility.ToAppRelative("~/Images/Blah.png"));
            // Hack to use ResolveClientUrl without including a Server.Execute in the sample
        tw.WriteLine("new Image().ResolveClientUrl(\"~/Images/Blah.png\"): " + new Image().ResolveClientUrl("~/Images/Blah.png"));
        return tw.ToString();
    }
}

Если вы запустите этот же код в ASP.NET 3.5 и ASP.NET 4, вы получите разные выходные данные: 

3.5
---------------------------
VirtualPathUtility.ToAbsolute("~/Images/Blah.png"): /MyTest1/Images/Blah.png
VirtualPathUtility.ToAppRelative("~/Images/Blah.png"): ~/Images/Blah.png
new Image().ResolveClientUrl("~/Images/Blah.png"): Images/Blah.png

4.0
---------------------------
VirtualPathUtility.ToAbsolute("~/Images/Blah.png"): /MyTest1/Images/Blah.png
VirtualPathUtility.ToAppRelative("~/Images/Blah.png"): ~/Images/Blah.png
new Image().ResolveClientUrl("~/Images/Blah.png"): ../Images/Blah.png

Первые два вызова одинаковы, но вызов ResolveClientUrl ведет себя по-разному. Примечание: мы на самом деле не называем ResolveClientUrl, как это, это внутри страницы ASPX, которая Server.Execute 'd, я просто сделал это, чтобы сохранить небольшой размер выборки - проблема, похоже, та же.

Итак ... Это ошибка? Можно ли как-нибудь заставить эту работу работать так же, как в ASP.NET 4, чтобы избежать необходимости перемещать ее так, чтобы пути работали правильно?

1 Ответ

0 голосов
/ 13 октября 2011

Похоже, это может быть преднамеренное изменение (исправление ошибки?) в ASP.NET 4.0, поэтому пути возвращаются правильно, чтобы браузеры могли их интерпретировать, например. 

/MyFolder/MyPage.aspx/Something/Something

В ASP.NET URL-адреса будут неверными, поскольку они будут основаны на /MyFolder/MyPage.aspx.

Я не думаю, что поведение ASP.NET 3.5 было действительно когда-либо правильным, это именно то, что мы использовали, потому что так оно и было, и теперь оно сломалось.

Мое решение на данный момент состоит в том, чтобы переместить файлы asmx на один уровень вверх, чтобы они находились на уровне выше страниц, на которые записывается их содержимое. Это очень неприятно и работает, только если ваши страницы находятся в папке, но это проще, чем переписать, как это работает!

...