Поделиться через

Критические изменения в ASP.NET 4

  • Статья

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

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

Содержимое

Параметр ControlRenderingCompatibilityVersion в файле Web.config
Изменения ClientIDMode
HtmlEncode и UrlEncode теперь кодируют одинарные кавычки
ASP.NET page (ASPX) — средство синтаксического анализа строгее
Обновлены файлы определения браузера
System.Web.Mobile.dll удалены из корневого файла веб-конфигурации
ASP.NET
Алгоритм хэширования по умолчанию теперь — HMACSHA256
Ошибки конфигурации, связанные с новой корневой конфигурацией ASP.NET 4
ASP.NET 4 дочерних приложений не удается запустить при использовании приложений ASP.NET 2.0 или ASP.NET 3.5
ASP.NET 4 веб-сайты не запускались на компьютерах, на которых установлен SharePoint
Свойство HttpRequest.FilePath больше не включает значения PathInfo
ASP.NET 2.0 приложения могут создавать ошибки HttpException, ссылающиеся на eurl.axd
Обработчики событий могут не вызываться в документе по умолчанию в интегрированном режиме IIS 7 или IIS 7.5
Изменения в реализации ASP.NET Code Access Security (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 не отображает атрибут имени .
  • Элемент управления Таблица больше не отображает border="0" атрибут.
  • Элементы управления, которые не предназначены для ввода пользователем (например, элемент управления Метка ), больше не отрисовывают disabled="disabled" атрибут, если для их свойства Enabled задано значение false (или если они наследуют этот параметр от контейнерного элемента управления).

Изменения ClientIDMode

Параметр ClientIDMode в ASP.NET 4 позволяет указать, как ASP.NET создает атрибут id для элементов 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) является более строгим

Средство синтаксического анализа страниц ASP.NET (.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 проверки подлинности на основе форм, должны работать across.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 machine.config содержит "4.0" в атрибуте type для одних и те же обработчиков разделов конфигурации, приложения, созданные в Visual Studio 2008 или Visual Studio 2008 с пакетом обновления 1 (SP1), всегда не выполняют проверку конфигурации в IIS 7 и IIS 7.5.

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

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

Альтернативным обходным решением для первого сценария является установка пакета обновления 2 (SP2) для 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 файл для the.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).

Web.config В файле родительского веб-приложения, работающего 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'.

Эта ошибка возникает из-за того, что инфраструктура безопасности доступа к коду (CAS) 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 теперь отображает значение атрибута действия элемента HTML-формы в виде пустой строки при запросе к 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. Если атрибут action является пустой строкой, объект IIS DefaultDocumentModule создаст дочерний запрос к Default.aspx. В большинстве случаев этот дочерний запрос прозрачен для кода приложения, и Default.aspx страница выполняется в обычном режиме.

Однако возможное взаимодействие между управляемым кодом и интегрированным режимом IIS 7 или 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, измените код страницы, чтобы явно задать свойству Action элемента управления HtmlForm значение Default.aspx.

Изменения в реализации ASP.NET Code Access Security (CAS)

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

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

<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 были перемещены в новый класс System.Net.WebUtility платформа .NET Framework 4. Если это единственная ASP.NET функция, которая использовалась, измените код приложения, чтобы использовать новый класс WebUtility .

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

  • ASP.NET домены приложений теперь являются однородными доменами приложений. В домене приложения доступны только наборы предоставления разрешений с частичным и полным доверием.
  • ASP.NET наборы предоставления разрешений с частичным доверием не зависят от любой политики АДМИНИСТРИРОВАНИЯ корпоративного уровня, уровня компьютера или пользователя.
  • ASP.NET сборки, поставляемые в версии 3.5 и 3.5 с пакетом обновления 1 (SP1), были преобразованы для использования модели прозрачности платформа .NET Framework 4.
  • Использование атрибута ASP.NET AspNetHostingPermission значительно сократилось. Большинство экземпляров этого атрибута были удалены из общедоступных API ASP.NET.
  • Динамически скомпилированные сборки, созданные поставщиками сборок 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, даже если типы членства были перемещены в другую сборку. В версию System.Web.dll ASP.NET 4 добавлена информация о переадресации типов, которая автоматически направляет ссылки времени выполнения для этих типов в новое расположение для типов.

Однако библиотеки классов, использующие определенные типы членства и обновленные с более ранних версий 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-заголовка

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

В 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","*");

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

Типы System.Web.Security для 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-адрес изображения непосредственно в элементе управления Меню с помощью свойства 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 было изменено. Дополнительные сведения см. в разделе Свойству MenuItem.PopOutImageUrl не удается отобразить изображение в ASP.NET 4 в этом документе.

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

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

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

Данный технический документ предназначен только для ознакомительных целей. МАЙКРОСОФТ НЕ ПРЕДОСТАВЛЯЕТ НИКАКИХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПРЕДУСМОТРЕННЫХ ЗАКОНОДАТЕЛЬСТВОМ, ОТНОСИТЕЛЬНО СВЕДЕНИЙ, СОДЕРЖАЩИХСЯ В ДАННОМ ДОКУМЕНТЕ.

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

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

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

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

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

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