ASP.NET 4 изменения, нарушающие совместимость

В этом документе описываются изменения, внесенные в выпуск .NET Framework версии 4, которые могут повлиять на приложения, созданные с помощью предыдущих выпусков, включая выпуски ASP.NET 4 бета-версии 1 и бета-версии 2.

Скачайте этот технический документ

Содержимое

Параметр ControlRenderingCompatibilityVersion в файле Web.config
Изменения режима ClientID
HtmlEncode и UrlEncode теперь кодируют одинарные кавычки
Анализатор страниц ASP.NET (.aspx) стал строже
Обновленные файлы определений браузера
удалён из корневого файла конфигурации веб

Алгоритм хэширования по умолчанию теперь HMACSHA256
Ошибки конфигурации, связанные с корневой конфигурацией ASP.NET 4
Дочерние приложения ASP.NET 4 не удается запустить, когда они находятся под управлением приложений ASP.NET 2.0 или ASP.NET 3.5
4 веб-сайтов не удается запустить на компьютерах, на которых установлена SharePoint
Свойство HttpRequest.FilePath больше не включает значения PathInfo
ASP.NET приложения 2.0 могут создавать ошибки HttpException, ссылающиеся на eurl.axd
Обработчики событий могут не вызываться в документе по умолчанию в режиме интеграции IIS 7 или IIS 7.5.
Изменения в реализации безопасности доступа к коду ASP.NET (CAS)
Тип MembershipUser и другие типы в пространстве имен System.Web.Security были перенесены
Изменения кэширования выходных данных, чтобы варьировать заголовок HTTP
Типы System.Web.Security для Passport являются устаревшими
Свойство MenuItem.PopOutImageUrl не удается отобразить изображение в ASP.NET 4
Menu.StaticPopOutImageUrl и Menu.DynamicPopOutImageUrl не отображают изображения, когда пути содержат обратные слэши
Отказ от ответственности

Параметр ControlRenderingCompatibilityVersion в файле Web.config

элементы управления ASP.NET были изменены в .NET Framework версии 4, чтобы указать более точное представление разметки. В предыдущих версиях .NET Framework некоторые элементы управления выдавали разметку, которую нельзя отключить. По умолчанию ASP.NET 4 этот тип разметки больше не создается.

Если вы используете Visual Studio 2010 для обновления приложения с ASP.NET 2.0 или ASP.NET 3.5, средство автоматически добавляет параметр в Web.config файл, который сохраняет устаревшую отрисовку. Однако, если вы обновляете приложение, изменяя пул приложений в IIS для нацеливания на .NET Framework 4, ASP.NET по умолчанию использует новый режим отрисовки. Чтобы отключить новый режим отрисовки Web.config , добавьте следующий параметр в файл:

<pages controlRenderingCompatibilityVersion="3.5" />

Основные изменения отрисовки, вызванные новым поведением, следующие:

  • Элементы управления Image и ImageButton больше не отображают атрибут border="0".
  • Класс BaseValidator и элементы управления проверки, производные от него, больше не отображают красный текст по умолчанию.
  • Элемент управления HtmlForm не отображает атрибут name.
  • Элемент управления Table больше не отображает border="0" атрибут.
  • Элементы управления, которые не предназначены для ввода пользователем (например, элемент управления Label ) больше не отображает disabled="disabled" атрибут, если для свойства Enabled задано значение false (или если он наследует этот параметр из элемента управления контейнера).

Изменения ClientIDMode

Параметр ClientIDMode в ASP.NET 4 позволяет указать, как ASP.NET создает атрибут идентификатора для элементов HTML. В предыдущих версиях ASP.NET поведение по умолчанию эквивалентно параметру AutoID clientIDMode. Однако параметр по умолчанию теперь предсказуем.

Если вы используете Visual Studio 2010 для обновления приложения с ASP.NET 2.0 или ASP.NET 3.5, средство автоматически добавляет параметр в Web.config файл, который сохраняет поведение предыдущих версий .NET Framework. Однако при обновлении приложения путем изменения пула приложений в IIS для целевого объекта .NET Framework 4 ASP.NET использует новый режим по умолчанию. Чтобы отключить новый режим идентификатора клиента, добавьте следующий параметр в Web.config файл:

<pages clientIDMode="AutoID" />

HtmlEncode и UrlEncode теперь кодируют одинарные кавычки

В ASP.NET 4 методы HtmlEncode и UrlEncode классов HttpUtility и HttpServerUtility были обновлены, чтобы закодировать одинарный символ кавычки (') следующим образом:

  • Метод HtmlEncode кодирует экземпляры одной кавычки как '.
  • Метод UrlEncode кодирует экземпляры одной кавычки как %27.

Парсер ASP.NET (.aspx) более строгий.

Средство синтаксического анализа для страниц (.aspx файлов) и пользовательских элементов управления (.ascx файлов) в ASP.NET 4 более строгое и будучи более строгим, оно отклонит больше случаев недопустимой разметки. Например, следующие два фрагмента успешно проходили синтаксический анализ в предыдущих версиях ASP.NET, но теперь в ASP.NET 4 они вызывают ошибки синтаксического анализа.

<asp:HiddenField runat="server" ID="SomeControl" Value="sampleValue"  ; />

Обратите внимание на недопустимую точку с запятой в конце тега HiddenField .

<asp:LinkButton runat="server" ID="SomeControl" onclick="someControlClicked"
      style="display:inline;  CssClass="searchLink"  />

Обратите внимание на незакрытый атрибут стиля, который пересекается с атрибутом CssClass.

Обновленные файлы определений браузера

Файлы определения браузера были обновлены, чтобы включить сведения о новых и обновленных браузерах и устройствах. Были удалены старые браузеры и устройства, такие как Netscape Navigator, и добавлены новые браузеры и устройства, такие как Google Chrome и Apple iPhone.

Если приложение содержит пользовательские определения браузера, наследуемые от одного из определений браузера, которые были удалены, появится сообщение об ошибке. Например, если App_Browsers папка содержит определение браузера, наследуемое от определения браузера IE2, вы получите следующее сообщение об ошибке конфигурации:

  • Не удается найти элемент браузера или шлюза с идентификатором IE2.

Замечание

Объект HttpBrowserCapabilities (который предоставляется свойством Request.Browser страницы) управляется файлами определений браузера. Таким образом, сведения, возвращаемые путем доступа к свойству этого объекта в ASP.NET 4, могут отличаться от сведений, возвращаемых в более ранней версии ASP.NET.

Чтобы вернуться к старым файлам определения браузера, скопируйте файлы определения браузера из следующей папки:

Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers

Скопируйте файлы в соответствующую \CONFIG\Browsers папку для ASP.NET 4. После копирования файлов запустите средство командной строки Aspnet_regbrowsers.exe.

System.Web.Mobile.dll удалены из корневого файла веб-конфигурации

В предыдущих версиях ASP.NET ссылка на сборку System.Web.Mobile.dll была включена в корневой Web.config файл в разделе сборок. Чтобы повысить производительность, ссылка на эту сборку была удалена.

Сборка System.Web.Mobile.dll включена в ASP.NET 4, но не рекомендуется. Если вы хотите использовать типы из сборки System.Web.Mobile.dll, добавьте ссылку на эту сборку в корневой Web.config файл или в файл приложения Web.config . Например, если вы хотите использовать любой из устаревших мобильных элементов управления ASP.NET, необходимо добавить ссылку на сборку System.Web.Mobile.dll в файл Web.config.

проверка запросов ASP.NET

Функция проверки запросов в ASP.NET обеспечивает определенный уровень защиты по умолчанию от атак XSS. В предыдущих версиях ASP.NET проверка запросов была включена по умолчанию. Однако она применяется только к ASP.NET страницам (.aspx файлам и файлам класса) и только при выполнении этих страниц.

По умолчанию в ASP.NET 4 проверка запросов включена для всех запросов, так как она включена до этапа BeginRequest HTTP-запроса. В результате проверка запросов применяется ко всем ASP.NET ресурсам, а не только к запросам страниц .aspx. К ним относятся такие запросы, как вызовы веб-службы и пользовательские обработчики HTTP. Проверка запросов также активна, если пользовательские модули HTTP считывают содержимое HTTP-запроса.

В результате ошибки проверки запросов теперь могут возникать для запросов, которые ранее не вызвали ошибки. Чтобы вернуться к поведению функции проверки запроса ASP.NET 2.0, добавьте следующий параметр в Web.config файл:

<httpRuntime requestValidationMode="2.0" />

Однако рекомендуется проанализировать ошибки проверки запросов, чтобы определить, могут ли существующие обработчики, модули или другие пользовательские коды получить потенциально небезопасные входные данные HTTP, которые могут быть векторами атак XSS.

Алгоритм хэширования по умолчанию теперь HMACSHA256

ASP.NET использует алгоритмы шифрования и хэширования для защиты данных, таких как файлы cookie проверки подлинности форм и состояние просмотра. По умолчанию ASP.NET 4 теперь использует алгоритм HMACSHA256 для хэш-операций с файлами cookie и состояния просмотра. Более ранние версии ASP.NET использовали старый алгоритм HMACSHA1.

Ваши приложения могут быть затронуты, если вы используете смешанные среды ASP.NET 2.0/ASP.NET 4, где данные, такие как файлы cookie аутентификации форм, должны работать между версиями .NET Framework. Чтобы настроить веб-приложение ASP.NET 4 для использования старого алгоритма HMACSHA1, добавьте следующий параметр в Web.config файл:

<machineKey validation="SHA1" />

Корневые файлы конфигурации (файл machine.config и корневой файл Web.config) для .NET Framework 4 (и, соответственно, ASP.NET 4) были обновлены, чтобы включить большую часть основной информации о конфигурации, которая в ASP.NET 3.5 была найдена в файлах приложения Web.config. Из-за сложности управляемых систем конфигурации IIS 7 и IIS 7.5, выполнение этих приложений ASP.NET 3.5 под управлением ASP.NET 4 и под IIS 7 и IIS 7.5 может привести к ошибкам конфигурации ASP.NET или IIS.

Рекомендуется обновить приложения ASP.NET версии 3.5 до ASP.NET 4 с помощью средств обновления проекта в Visual Studio 2010, если это практически. Visual Studio 2010 автоматически изменяет файл приложения Web.config ASP.NET 3.5, чтобы он содержал соответствующие параметры для ASP.NET 4.

Однако это поддерживаемый сценарий для запуска ASP.NET приложений версии 3.5 с помощью .NET Framework 4 без повторной компиляции. В этом случае может потребоваться вручную изменить файл Web.config приложения перед его запуском в .NET Framework 4 и в IIS 7 или IIS 7.5.

В следующих двух разделах описываются изменения, которые могут потребоваться для различных сочетаний программного обеспечения.

Windows Vista с пакетом обновления 1 (SP1) или Windows Server 2008 с пакетом обновления 1 (SP1), где не установлены ни исправление KB958854, ни пакет обновления 2 (SP2). В этой конфигурации система конфигурации IIS 7 неправильно объединяет управляемую конфигурацию приложения, сравнивая файл уровня Web.config приложения с файлами ASP.NET 2.0 machine.config . Из-за этого файлы уровня Web.config приложения из .NET Framework 3.5 или более поздней версии должны иметь определение раздела конфигурации system.web.extensions (элемент), чтобы не вызвать сбой проверки IIS 7.

Однако записи файлов на уровне Web.config приложения, которые были изменены вручную и не полностью совпадают с исходными шаблонными определениями разделов конфигурации, введенными в Visual Studio 2008, будут вызывать ошибки конфигурации ASP.NET. (Записи конфигурации по умолчанию, созданные Visual Studio 2008, работают правильно.) Распространенная проблема заключается в том, что измененные вручную Web.config файлы опускают атрибуты allowDefinition и requirePermission, которые находятся в различных определениях разделов конфигурации. Это приводит к несоответствию между сокращенным разделом конфигурации в файлах на уровне Web.config приложения и полным определением в файле ASP.NET 4 machine.config . В результате во время выполнения система конфигурации ASP.NET 4 вызывает ошибку конфигурации.

Windows Vista SP2, Windows Server 2008 с пакетом обновления 2 (SP2), Windows 7, Windows Server 2008 R2, а также Windows Vista с пакетом обновления 1 (SP1) и Windows Server 2008 с пакетом обновления 1 (SP1), где установлен KB958854 исправлений.

В этом сценарии собственная система конфигурации IIS 7 и IIS 7.5 возвращает ошибку конфигурации, так как она проводит текстовое сравнение атрибута тип, определенного для управляемого обработчика раздела конфигурации. Так как все Web.config файлы, созданные в Visual Studio 2008 и Visual Studio 2008 с пакетом обновления 1 (SP1), имеют значение "3.5" в строке типа для обработчиков секций конфигурации system.web.extensions (и связанных с ними), а файл ASP.NET 4 имеет "4.0" в атрибуте типа для тех же обработчиков секций конфигурации, приложения, созданные в Visual Studio 2008 или Visual Studio 2008 SP1, всегда не проходят проверку конфигурации в IIS 7 и IIS 7.5.

Устранение этих проблем

Решением первого сценария является обновление файла на уровне Web.config приложения, включив в файл конфигурации стандартный текст из Web.config файла, который был создан автоматически Visual Studio 2008.

Альтернативным решением для первого сценария является установка 2-го пакета обновлений для Vista или Windows Server 2008 на компьютере, чтобы исправить неправильное поведение объединения конфигураций в системе конфигурации IIS. Однако после выполнения любого из этих действий приложение, скорее всего, столкнется с ошибкой конфигурации из-за проблемы, описанной во втором сценарии.

Обходной путь для второго сценария — удалить или закомментировать все определения разделов конфигурации system.web.extensions и определения групп разделов конфигурации из файла уровня Web.config приложения. Эти определения обычно находятся в верхней части файла уровня Web.config приложения и могут быть определены элементом configSections и его дочерними элементами.

В обоих сценариях рекомендуется также вручную удалить раздел system.codedom , хотя это не обязательно.

ASP.NET 4 дочерние приложения не запускаются, когда работают под управлением ASP.NET 2.0 или ASP.NET 3.5 приложения.

ASP.NET 4 приложения, настроенные как дочерние приложения, запускающие более ранние версии ASP.NET, могут не запускаться из-за ошибок конфигурации или компиляции. В следующем примере показана структура каталогов для затронутого приложения.

/parentwebapp (настроено использование ASP.NET 2.0 или ASP.NET 3.5)
/childwebapp (настроено использование ASP.NET 4)

Приложение в папке childwebapp не сможет запуститься в IIS 7 или IIS 7.5 и сообщит об ошибке конфигурации. Текст ошибки будет содержать сообщение, аналогичное следующему:

  • The requested page cannot be accessed because the related configuration data for the page is invalid.

  • The configuration section 'configSections' cannot be read because it is missing a section declaration.

В IIS 6 приложение в папке childwebapp также не удается запустить, но будет сообщать о другой ошибке. Например, текст ошибки может указать следующее:

  • The value for the 'compilerVersion' attribute in the provider options must be 'v4.0' or later if you are compiling for version 4.0 or later of the .NET Framework. To compile this Web application for version 3.5 or earlier of the .NET Framework, remove the 'targetFramework' attribute from the element of the Web.config file

Эти сценарии возникают из-за того, что сведения о конфигурации родительского приложения в parentwebapp папке являются частью иерархии сведений о конфигурации, которая определяет окончательные объединенные параметры конфигурации, используемые дочерним веб-приложением в папке childwebapp . В зависимости от того, работает ли веб-приложение ASP.NET 4 в IIS 7 (или IIS 7.5) или в IIS 6, система конфигурации IIS или система компиляции ASP.NET 4 вернет ошибку.

Действия, которые необходимо выполнить, чтобы устранить эту проблему и получить дочернее приложение ASP.NET 4 для работы, зависит от того, работает ли приложение ASP.NET 4 в IIS 6 или IIS 7 (или IIS 7.5).

Шаг 1 (только iis 7 или IIS 7.5)

Этот шаг необходим только в операционных системах под управлением IIS 7 или IIS 7.5, включая Windows Vista, Windows Server 2008, Windows 7 и Windows Server 2008 R2.

Переместите определение configSections из файла Web.config родительского приложения (приложение, работающего на ASP.NET 2.0 или ASP.NET 3.5) в корневой файл Web.config для .NET Framework 2.0. Встроенная система конфигурации IIS 7 и IIS 7.5 сканирует элемент configSections при слиянии иерархии файлов конфигурации. Перемещение определения configSections из файла родительского веб-приложения в корневой Web.config файл фактически скрывает элемент из процесса слияния конфигурации, который происходит для дочернего приложения Web.config ASP.NET 4.

В 32-разрядной операционной системе или в 32-разрядных пулах приложений корневой Web.config файл для ASP.NET 2.0 и ASP.NET 3.5 обычно находится в следующей папке:

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

В 64-разрядной операционной системе или в 64-разрядных пулах приложений корневой Web.config файл для ASP.NET 2.0 и ASP.NET 3.5 обычно находится в следующей папке:

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

Если вы запускаете 32-разрядные и 64-разрядные веб-приложения на 64-разрядном компьютере, необходимо переместить элемент configSections в корневые Web.config файлы как для 32-разрядных, так и для 64-разрядных систем.

Когда элемент 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 дочернего веб-приложения в IIS 6 или IIS 7 (или IIS 7.5).

В файле родительского веб-приложения, работающего на ASP.NET 2 или ASP.NET 3.5, добавьте тег , который явно указывает, как для системы конфигурации IIS, так и для ASP.NET, что настройки относятся только к родительскому веб-приложению. В следующем примере показан синтаксис добавляемого элемента location :

<location path="" inheritInChildApplications="false" >
  <!-- Additional settings -->
</location>

В следующем примере показано, как тег расположения используется для упаковки всех разделов конфигурации, начиная с раздела appSettings и заканчивая разделом system.webServer .

<location path="" inheritInChildApplications="false" >
  <appSettings />
  <connectionStrings />
  <system.web>
    <!-- Removed for brevity -->
  </system.web>
  <system.codedom>
    <!-- Removed for brevity -->
  </system.codedom>
  <system.webServer>
    <!-- Removed for brevity -->
</system.webServer>
</location>

После выполнения шагов 1 и 2 дочерние ASP.NET 4 веб-приложения будут запускаться без ошибок.

ASP.NET 4 веб-сайтов не удается запустить на компьютерах, на которых установлена SharePoint

Веб-серверы, на которых выполняется SharePoint, имеют Web.config файл, развернутый в корне веб-сайта SharePoint (например, c:\inetpub\wwwroot\web.config для веб-сайта по умолчанию). В этом Web.config файле SharePoint устанавливает пользовательский уровень частичного доверия под названием WSS_Minimal.

Если вы пытаетесь запустить веб-сайт ASP.NET 4, развернутый как дочерний веб-сайт этого типа SharePoint, появится следующая ошибка:

Could not find permission set named 'ASP.NET'.

Эта ошибка возникает из-за того, что инфраструктура безопасности доступа к коду ASP.NET 4 ищет набор разрешений с именем ASP.NET. Однако файл конфигурации частичного доверия, на который ссылается WSS_Minimal, не содержит наборов разрешений с таким именем.

В настоящее время отсутствует версия SharePoint, совместимая с ASP.NET. В результате не следует пытаться запустить веб-сайт ASP.NET 4 в качестве дочернего сайта под веб-сайтами SharePoint.

Свойство HttpRequest.FilePath больше не включает значения PathInfo

Предыдущие версии ASP.NET включали значение PathInfo в значение, возвращаемое из различных свойств пути к файлу, включая HttpRequest.FilePath, HttpRequest.AppRelativeCurrentExecutionFilePath и HttpRequest.CurrentExecutionFilePath. ASP.NET 4 больше не содержит значение PathInfo в возвращаемых значениях из этих свойств. Вместо этого сведения PathInfo доступны в HttpRequest.PathInfo. Например, представьте следующий фрагмент URL-адреса:

/testapp/Action.mvc/SomeAction

В более ранних версиях ASP.NET свойства HttpRequest имеют следующие значения:

HttpRequest.FilePath: /testapp/Action.mvc/SomeAction

HttpRequest.PathInfo: (пустой)

В ASP.NET 4 свойства HttpRequest вместо этого имеют следующие значения:

HttpRequest.FilePath: /testapp/Action.mvc

HttpRequest.PathInfo: SomeAction

Приложения ASP.NET версии 2.0 могут вызывать ошибки HttpException, указывающие на eurl.axd.

После того как ASP.NET 4 активирован в IIS 6, приложения ASP.NET 2.0, работающие на IIS 6 (в Windows Server 2003 или Windows Server 2003 R2), могут вызвать такие ошибки, как следующие:

System.Web.HttpException: Path '/[yourApplicationRoot]/eurl.axd/[Value]' was not found.

Эта ошибка возникает из-за того, что ASP.NET обнаруживает, что веб-сайт настроен на использование ASP.NET 4, собственный компонент ASP.NET 4 передает URL-адрес без расширения управляемой части ASP.NET для дальнейшей обработки. Однако если виртуальные каталоги ниже веб-сайта ASP.NET 4 настроены для использования ASP.NET 2.0, обработка URL-адреса без расширения таким образом приводит к изменению URL-адреса, содержащего строку "eurl.axd". Затем этот измененный URL-адрес отправляется в приложение ASP.NET 2.0. ASP.NET 2.0 не может распознать формат eurl.axd. Поэтому ASP.NET 2.0 пытается найти файл с именем eurl.axd и выполнить его. Так как такой файл не существует, запрос завершается с исключением HttpException.

Эту проблему можно обойти с помощью одного из следующих вариантов.

Вариант 1

Если для работы веб-сайта не требуется ASP.NET 4, переназначьте сайт на использование ASP.NET 2.0.

Вариант 2

Если для работы веб-сайта требуется ASP.NET 4, переместите все дочерние виртуальные каталоги ASP.NET 2.0 на другой веб-сайт, сопоставленный с ASP.NET 2.0.

Вариант 3

Если невозможно переназначить веб-сайт для работы с ASP.NET 2.0 или изменить расположение виртуального каталога, явно отключите обработку URL-адресов без расширений в ASP.NET 4. Это можно сделать следующим образом:

  1. В реестре Windows откройте следующий узел:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0

  1. Создайте новое значение DWORD с именем EnableExtensionlessUrls.
  2. Задайте для EnableExtensionlessUrls значение 0. Это отключает функцию обработки URL-адресов без расширения.
  3. Сохраните значение реестра и закройте редактор реестра.
  4. Запустите средство командной строки iisreset , которое приводит к чтению нового значения реестра IIS.

Замечание

Установка параметра EnableExtensionlessUrls на 1 позволяет использовать поведение безрасширенных URL-адресов. Это параметр по умолчанию, если значение не указано.

Возможно, обработчики событий не будут вызываться в документе по умолчанию в интегрированном режиме IIS 7 или IIS 7.5.

ASP.NET 4 включает изменения, которые изменяют способ отображения атрибута action элемента формы HTML, когда URL-адрес без расширения преобразуется в документ по умолчанию. Пример URL-адреса без расширения, ссылающегося на документ по умолчанию, http://contoso.com/ приведет к запросу http://contoso.com/Default.aspx.

ASP.NET 4 теперь отображает значение атрибута action элемента HTML form как пустую строку, когда запрос направляется на URL без расширения, к которому сопоставлен документ по умолчанию. Например, в предыдущих выпусках ASP.NET запрос к http://contoso.com приводил бы к запросу к Default.aspx. В этом документе откроется тег формы , как показано в следующем примере:

<form action="Default.aspx" />

В ASP.NET 4 запрос http://contoso.com также приводит к запросу Default.aspx. Однако теперь ASP.NET отображает HTML-тег открытия формы, как показано в следующем примере:

<form action="" />

Это различие в том, как обрабатывается атрибут действия, может привести к немногочисленным изменениям в обработке отправки данных формы службами IIS и ASP.NET. Если атрибут действия является пустой строкой, объект IIS DefaultDocumentModule создаст дочерний запрос Default.aspx. В большинстве случаев этот дочерний запрос является прозрачным для кода приложения, и Default.aspx страница выполняется обычно.

Однако потенциальное взаимодействие между управляемым кодом и интегрированным режимом IIS 7.5 может привести к тому, что управляемые .aspx страницы перестают работать должным образом во время дочернего запроса. Если возникают следующие условия, дочерний запрос к Default.aspx документу приведет к ошибке или непредвиденному поведению:

  1. Страница .aspx отправляется в браузер с атрибутом действия элемента формы, равным "".
  2. Форма размещается обратно в ASP.NET.
  3. Управляемый модуль HTTP считывает часть содержимого сущности. Например, модуль считывает Request.Form или Request.Params. Это приводит к тому, что текст сущности запроса POST будет считываться в управляемую память. В результате тело сущности больше недоступно для любых модулей исходного кода, работающих в режиме интеграции в IIS 7 или IIS 7.5.
  4. Объект IIS DefaultDocumentModule в конечном итоге выполняется и создает дочерний запрос к документу Default.aspx . Тем не менее, поскольку тело сущности уже было прочитано фрагментом управляемого кода, текст сущности недоступен для отправки дочернему запросу.
  5. Когда конвейер HTTP запускается для дочернего запроса, обработчик файлов .aspx запускается во время этапа выполнения обработчика.
  6. Поскольку тело сущности отсутствует, переменные формы и состояние представления отсутствуют, поэтому для обработчика страницы .aspx нет сведений, чтобы определить, какое событие (если есть) должно быть вызвано. В результате ни один из обработчиков событий постбэка для затронутой .aspx страницы не выполняется.

Это поведение можно обойти следующим образом:

  • Определите http-модуль, который обращается к тексту сущности запроса во время запросов документов по умолчанию и определите, можно ли настроить его для запуска только для управляемых запросов. В интегрированном режиме для IIS 7 и IIS 7.5 модули HTTP можно пометить только для управляемых запросов, добавив следующий атрибут в запись system.webServer/modules модуля:

  • precondition="managedHandler"

  • Этот параметр отключает модуль для запросов, которые IIS 7 и IIS 7.5 определяют как не управляемые запросы. Для запросов документов по умолчанию первый запрос — это URL-адрес без расширения. Поэтому службы IIS не запускают управляемые модули, которые отмечены предварительным условием управляемого обработчика, при первоначальной обработке запросов. В результате управляемые модули не будут случайно считывать тело сущности, поэтому тело сущности по-прежнему доступно и передается дочернему запросу и документу по умолчанию.

  • Если проблемные модули HTTP должны выполняться для всех запросов (для статических файлов, для URL-адресов без расширения, разрешающих объект DefaultDocumentModule , для управляемых запросов и т. д.), измените затронутые .aspx страницы, явно задав свойство Action элемента управления System.Web.UI.HtmlControls.HtmlForm в непустую строку. Например, если документ по умолчанию Default.aspx, измените код страницы, чтобы явно задать для свойства HtmlForm элемента управления Action значение "Default.aspx".

Изменения в реализации безопасности доступа к коду ASP.NET (CAS)

ASP.NET 2.0 и расширения функций ASP.NET, добавленных в версии 3.5, используют модель безопасности доступа к коду (CAS) .NET Framework 1.1 и 2.0. Однако реализация CAS в ASP.NET 4 была существенно изменена. В результате ASP.NET приложения с частичным доверием, использующие доверенный код, работающий в глобальном кэше сборок (GAC), могут завершиться сбоем с различными исключениями безопасности. Приложения с частичным доверием, использующие обширные изменения политики CAS компьютера, также могут столкнуться с исключениями безопасности.

Вы можете восстановить поведение частично-доверенных приложений ASP.NET 4 до версии ASP.NET 1.1 и 2.0 с помощью нового атрибута legacyCasModel в элементе конфигурации trust, как показано в следующем примере:

<trust level= "Medium" legacyCasModel="true" />

При возврате к устаревшей модели CAS включено следующее старое поведение CAS:

  • Политика CAS компьютера учитывается.
  • Разрешено несколько разных наборов разрешений в одном домене приложения.
  • Явные утверждения разрешений не требуются для сборок в GAC, которые вызываются на стеке с кодом только ASP.NET или других компонентов .NET Framework.

Один сценарий нельзя восстановить в .NET Framework 4: частичные доверенные приложения, не связанные с веб, больше не могут вызывать определенные API в System.Web.dll и System.Web.Extensions.dll. В предыдущих версиях .NET Framework можно было явно предоставлять разрешения AspNetHostingPermission для небраузерных приложений с частичным уровнем доверия. Затем эти приложения могут использовать System.Web.HttpUtility, типы в пространствах имен System.Web.ClientServices.* и типы, связанные с членством, ролями и профилями. Вызов этих типов из частично доверенных приложений, не связанных с веб, больше не поддерживается в .NET Framework 4.

Замечание

Функции HtmlEncode и HtmlDecode класса System.Web.HttpUtility были перенесены в новый класс .NET Framework 4 System.Net.WebUtility . Если это была единственная ASP.NET функциональность, используемая, измените код приложения, чтобы использовать новый класс WebUtility .

Ниже приведены общие сведения об изменениях реализации CAS по умолчанию в ASP.NET 4.

  • ASP.NET домены приложений теперь являются однородными доменами приложений. В домене приложения доступны только наборы предоставления частичного доверия и полного доверия.
  • ASP.NET наборы предоставления частичного доверия не зависят от любой корпоративной политики, политики на уровне компьютера или политики CAS на уровне пользователя.
  • Сборки ASP.NET, выпущенные в версиях 3.5 и 3.5 с пакетом обновления 1 (SP1), перешли на использование модели прозрачности .NET Framework 4.
  • Использование ASP.NET атрибута AspNetHostingPermission значительно сократилось. Большинство экземпляров этого атрибута были удалены из общедоступных ASP.NET API.
  • Динамически скомпилированные сборки, созданные ASP.NET поставщиками сборок, были обновлены, чтобы явно пометить сборки как прозрачные.
  • Все сборки ASP.NET теперь помечены таким образом, что атрибут APTCA учитывается только в средах веб-хостинга. Частично доверенные ненадежные среды размещения, такие как ClickOnce, не смогут вызывать ASP.NET сборки.

Дополнительные сведения о новой модели безопасности доступа к коду ASP.NET 4 см. в разделе "Использование безопасности доступа к коду" в приложениях ASP.NET на веб-сайте MSDN.

Члены MembershipUser и другие типы в пространстве имен System.Web.Security были перемещены

Некоторые типы, используемые в подсистеме членства ASP.NET, были перенесены из System.Web.dll в новую сборку System.Web.ApplicationServices.dll. Типы были перемещены для разрешения зависимостей архитектурного слоя между типами в клиенте и расширенных SKU .NET Framework.

Проекты веб-сайта не имеют проблем в результате перемещения этих типов, так как System.Web.ApplicationServices.dll был добавлен в список ссылочных сборок, используемых по умолчанию системой компиляции ASP.NET. При обновлении проекта веб-сайта, созданного с помощью более ранней версии ASP.NET до ASP.NET 4, открыв его в Visual Studio 2010, проект будет компилироваться без ошибок.

Аналогичным образом, если вы обновляете проект веб-приложения, созданный в более ранней версии ASP.NET до ASP.NET 4, открыв его в Visual Studio 2010, процесс обновления добавляет ссылку на System.Web.ApplicationServices.dll в проект. Поэтому обновленные проекты веб-приложения также будут компилироваться без ошибок.

Скомпилированные (двоичные) файлы, созданные с помощью более ранних версий ASP.NET, также будут выполняться без ошибок в ASP.NET 4, даже несмотря на то, что типы членства были перемещены в другую сборку. Сведения о перенаправлении типов были добавлены в версию ASP.NET 4 System.Web.dll, которая автоматически направляет ссылки времени выполнения этих типов в новое расположение этих типов.

Однако библиотеки классов, использующие определенные типы членства и обновленные из более ранних версий ASP.NET, не будут компилироваться при использовании в проекте ASP.NET 4. Например, проект библиотеки классов может не компилировать и сообщить об ошибке, например следующее:

  • The type 'System.Web.Security.MembershipUser' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Web.ApplicationServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.

  • The type name 'MembershipUser' could not be found. This type has been forwarded to assembly 'System.Web.ApplicationServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. Consider adding a reference to that assembly.

Эту проблему можно обойти, добавив ссылку на System.Web.ApplicationServices.dll в вашем проекте библиотеки классов.

В следующем списке показаны типы System.Web.Security, которые были перенесены из System.Web.dll в System.Web.ApplicationServices.dll.

  • System.Web.Security.MembershipCreateStatus
  • System.Web.Security.Membership.CreateUserException
  • System.Web.Security.MembershipPasswordException
  • System.Web.Security.MembershipPasswordFormat
  • System.Web.Security.MembershipProvider
  • System.Web.Security.MembershipProviderCollection
  • System.Web.Security.MembershipUser
  • System.Web.Security.MembershipUserCollection
  • System.Web.Security.MembershipValidatePasswordEventHandler
  • System.Web.Security.ValidatePasswordEventArgs
  • System.Web.Security.RoleProvider
  • System.Web.Configuration.MembershipPasswordCompatibilityMode

Изменения в кэшировании выходных данных для заголовка HTTP типа Vary

В ASP.NET 1.0 ошибка приводила к тому, что кэшированные страницы с параметром Location="ServerAndClient" для настройки выходного кэша выдавали в ответе HTTP-заголовок Vary:*. Это повлияло на то, что клиентские браузеры никогда не кэшируют страницу локально.

В ASP.NET 1.1 был добавлен метод System.Web.HttpCachePolicy.SetOmitVaryStar , который можно вызвать для подавления заголовка Vary:* . Этот метод был выбран, так как изменение генерируемого заголовка HTTP считалось потенциально критическим изменением в то время. Однако разработчики были смущены поведением в ASP.NET, и отчеты об ошибках предполагают, что разработчики не знают о существующем поведении SetOmitVaryStar .

В ASP.NET 4 было принято решение устранить корневую проблему. Заголовок Vary:* HTTP больше не выдается из ответов, указывающих следующую директиву:

<%@OutputCache Location="ServerAndClient" %>

В результате SetOmitVaryStar больше не требуется для подавления заголовка Vary:* .

В приложениях, которые указывают Location="ServerAndClient" в директиве @OutputCache на странице, теперь вы увидите поведение, подразумеваемое именем значения атрибута Location , то есть страницы будут кэшироваться в браузере, не требуя вызова метода SetOmitVaryStar .

Если страницы в приложении должны содержать Vary:*, вызовите метод AppendHeader, как показано в следующем примере:

HttpResponse.AppendHeader("Vary","*");

Кроме того, можно изменить значение атрибута расположения кэширования выходных данных на "Сервер".

Типы System.Web.Security для Microsoft Passport устарели

Поддержка Passport, встроенная в ASP.NET 2.0, устарела и не поддерживается в течение нескольких лет из-за изменений в Passport (теперь LiveID). В результате пять типов, связанных с Passport в System.Web.Security , теперь помечены атрибутом ObsoleteAttribute .

Свойство MenuItem.PopOutImageUrl не удается отобразить изображение в ASP.NET 4

В ASP.NET 3.5 свойство MenuItem.PopOutImageUrl позволяет указать URL-адрес изображения, отображаемого в элементе меню, чтобы указать, что элемент меню имеет динамический подменю. В следующем примере показано, как указать это свойство в разметке в ASP.NET 3.5.

<asp:menu id="NavigationMenu"
    staticdisplaylevels="1"
    staticsubmenuindent="10" 
    orientation="Vertical" 
    target="_blank"  
    runat="server">
  <items>
    <asp:menuitem navigateurl="default2.aspx" 
        text="Home" 
        PopOutImageUrl="~/Images/Popout.gif"   
        tooltip="Home">
      <asp:menuitem navigateurl="default3.aspx"
          text="Movies"
          PopOutImageUrl="~/Images/Popout.gif"
          tooltip="Movies"> 
      </asp:menuitem>
    </asp:menuitem>
  </items>
</asp:menu>

В результате изменения структуры ASP.NET 4 выходные данные не отображаются для PopOutImageUrl , если свойство задано для класса MenuItem . Вместо этого необходимо указать URL-адрес изображения непосредственно в элементе управления Menu с помощью свойства StaticPopOutImageUrl или свойства DynamicPopOutImageUrl . При работе со статическим меню свойство Menu.StaticPopOutImageUrl указывает URL-адрес изображения, отображаемого для отображения, чтобы указать, что статический элемент меню имеет подменю, как показано в следующем примере:

<asp:menu id="NavigationMenu"
    staticdisplaylevels="1"
    staticsubmenuindent="10" 
    orientation="Vertical" 
    target="_blank" 
    StaticPopOutImageTextFormatString="More..."
    StaticPopOutImageUrl="Images/Popout.gif"   
    runat="server">
  <items>
    <asp:menuitem navigateurl="default2.aspx" 
        text="Home" 
        tooltip="Home">
      <asp:menuitem navigateurl="default3.aspx"
          text="Movies"
          tooltip="Movies"> 
      </asp:menuitem>
    </asp:menuitem>
  </items>
</asp:menu>

Если вы работаете с динамическим меню, используйте свойство Menu.DynamicPopOutImageUrl , чтобы указать URL-адрес изображения, указывающего, что у динамического элемента меню есть подменю. Следующий пример аналогичен предыдущему, но показывает, как задать свойство DynamicPopOutImageUrl для динамического меню.

<asp:menu id="NavigationMenu"
    staticdisplaylevels="1"
    staticsubmenuindent="10" 
    orientation="Vertical" 
    target="_blank" 
    DynamicPopOutImageTextFormatString="More..."
    DynamicPopOutImageUrl="Images/Popout.gif" 
    runat="server">
  <items>
    <asp:menuitem navigateurl="default2.aspx" 
        text="Home" 
        tooltip="Home">
      <asp:menuitem navigateurl="default3.aspx"
          text="Movies"
          tooltip="Movies"> 
      </asp:menuitem>
    </asp:menuitem>
  </items>
</asp:menu>

Если свойство Menu.DynamicPopOutImageUrl не задано, а свойство Menu.DynamicEnableDefaultPopOutImage имеет значение false, изображение не отображается. Аналогичным образом, если свойство StaticPopOutImageUrl не задано, а свойство StaticEnableDefaultPopOutImage имеет значение false, изображение не отображается.

При установке путей для этих свойств используйте косую черту (/) вместо обратного слэша (). Дополнительные сведения см. в разделе Menu.StaticPopOutImageUrl и Menu.DynamicPopOutImageUrl не отображают изображения, если пути содержат обратные слеши в другом месте этого документа.

В ASP.NET 4 изображения, указанные с помощью свойств Menu.StaticPopOutImageUrl и Menu.DynamicPopOutImageUrl, не будут отображены, если путь содержит обратные слеши (). Изменение по сравнению с предыдущими версиями ASP.NET.

В следующем примере разметки элемента управления Menu показан набор свойств StaticPopOutImageUrl с помощью пути, содержащего обратную косую черту. В ASP.NET 4 изображение, указанное в свойстве, не будет отображаться.

<asp:menu id="NavigationMenu"
    staticdisplaylevels="1"
    staticsubmenuindent="10" 
    orientation="Vertical 
    target="_blank" 
    StaticPopOutImageTextFormatString="More..."
    StaticPopOutImageUrl="Images\Popout.gif"   
    runat="server">
  <items>
    <asp:menuitem navigateurl="default2.aspx" 
        text="Home" 
        tooltip="Home">
      <asp:menuitem navigateurl="default3.aspx"
          text="Movies"
          tooltip="Movies"> 
      </asp:menuitem>
    </asp:menuitem>
  </items>
</asp:menu>

Чтобы устранить эту проблему, измените значения пути, указанные в свойствах StaticPopOutImageUrl и DynamicPopOutImageUrl для использования косой черты (/). В следующем примере показано следующее изменение:

<asp:menu id="NavigationMenu"
    staticdisplaylevels="1"
    staticsubmenuindent="10" 
    orientation="Vertical 
    target="_blank" 
    StaticPopOutImageTextFormatString="More..."
    StaticPopOutImageUrl="Images/Popout.gif"   
    runat="server">
  <items>
    <asp:menuitem navigateurl="default2.aspx" 
        text="Home" 
        tooltip="Home">
      <asp:menuitem navigateurl="default3.aspx"
          text="Movies"
          tooltip="Movies"> 
      </asp:menuitem>
    </asp:menuitem>
  </items>
</asp:menu>

Обратите внимание, что приложения, перенесенные из более ранних версий ASP.NET в ASP.NET 4, также могут быть затронуты, так как свойство MenuItem.PopOutImageUrl было изменено. Дополнительные сведения см. в разделе Не удается отобразить изображение в ASP.NET 4 в этом документе.

Отказ от ответственности

Это предварительный документ и может быть существенно изменен до окончательного коммерческого выпуска программного обеспечения, описанного в этом документе.

Информация, содержащаяся в этом документе, являет собой текущее представление корпорации Майкрософт о вопросах, которые обсуждались на момент публикации. Поскольку корпорация Майкрософт должна реагировать на изменение рыночных условий, эта информация не должна рассматриваться как обязательство корпорации Майкрософт. Корпорация Майкрософт не может гарантировать достоверность информации, предоставленной после момента публикации.

Этот документ является исключительно информационным. КОРПОРАЦИЯ МАЙКРОСОФТ НЕ ПРЕДОСТАВЛЯЕТ НИКАКИХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ОТНОСИТЕЛЬНО СВЕДЕНИЙ В ЭТОМ ДОКУМЕНТЕ.

Ответственность за соблюдение всех авторских прав и прав на интеллектуальную собственность целиком и полностью несет пользователь. Не ограничивая прав в соответствии с авторским правом, ни одна часть этого документа не может быть воспроизведена, сохранена в системе извлечения, или передана в любой форме и любым способом (электронным, механическим, копирование, аудиозапись или иным способом) без явного письменного разрешения Корпорации Майкрософт.

Корпорация Майкрософт может иметь патенты, патентные заявки, охраняемые товарные знаки, авторские или другие права на интеллектуальную собственность применительно к содержимому этого документа. Без письменного разрешения корпорации Майкрософт данный документ не дает лицензии на эти патенты, охраняемые товарные знаки, авторские права и другую интеллектуальную собственность.

Если не указано иное, например компании, организации, продукты, доменные имена, адреса электронной почты, логотипы, люди, места и события, изображенные здесь, являются вымышленными и не связаны с любой реальной компанией, организацией, продуктом, доменным именем, адресом электронной почты, логотипом, логотипом, местом или событием.

© Корпорация Майкрософт 2010 г. Все права защищены.

Корпорация Майкрософт и Windows являются зарегистрированными товарными знаками или товарными знаками корпорации Майкрософт в США и /или других странах.

Названия фактических компаний и продуктов, упомянутых здесь, могут быть товарными знаками соответствующих владельцев.

  • Last updated on