Проблемы при переходе на .NET Framework 4

Статья
03/30/2023

В этой статье описываются проблемы при переходе между .NET Framework 3.5 с пакетом обновления 1 (SP1) и .NET Framework 4, в том числе исправления, изменения для соответствия стандартам и обеспечения безопасности, а также изменения, внесенные на основе отзывов пользователей. Большинство изменений не требуют каких-либо программных изменений в ваших приложениях. Случаи, требующие изменений, описаны в столбце Рекомендованные изменения таблицы. Важные изменения классифицированы по областям, например ASP.NET и Windows Presentation Foundation (WPF).

Более общий обзор рассмотренных в этой статье проблем см. в руководстве по переходу на .NET Framework 4.

Сведения о новых возможностях см. в статье Новые возможности .NET Framework 4.

ASP.NET и Интернет

Пространства имен: System.Web, System.Web.Mobile, System.Web.Security, System.Web.UI.WebControls

Сборка: System.Web (в System.Web.dll)

Функция	Отличия от версии 3.5 с пакетом обновления 1 (SP1)	Рекомендованные изменения
Файлы описания браузеров	Файлы описания браузеров обновлены: теперь они включают сведения о новых и обновленных браузерах и устройствах. Устаревшие браузеры и устройства (например, Netscape Navigator) удалены; добавлены новые браузеры и устройства (например, Google Chrome и Apple iPhone). Если ваше приложение содержит пользовательские описания браузеров, унаследованные от одного из удаленных описаний браузеров, произойдет ошибка. Объект HttpBrowserCapabilities (предоставляемый свойством `Request.Browse` страницы) управляется файлами описания браузеров. Поэтому информация, возвращаемая при обращении к свойству этого объекта в ASP.NET 4, может отличаться от информации, возвращаемой в более ранней версии ASP.NET.	Если в вашем приложении используются старые файлы описания браузеров, их можно скопировать из следующей папки: Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers Скопируйте файлы в соответствующую папку \CONFIG\Browsers для ASP.NET 4. После копирования файлов запустите программу командной строки Aspnet_regbrowsers.exe. Дополнительные сведения см. на веб-сайте https://www.asp.net/mobile.
Дочерние приложения, работающие под управлением нескольких версий ASP.NET	Приложения ASP.NET 4, которые настроены как дочерние для приложений, использующих предыдущие версии ASP.NET, могут не запускаться из-за ошибок конфигурации или компиляции. Конкретная ошибка зависит от того, где выполняется приложение — в IIS 6.0 или в IIS 7 либо IIS 7.5.	Чтобы система конфигурации правильно распознавала приложение ASP.NET 4, можно внести изменения в файлы конфигурации затронутых приложений. Сведения об изменениях, которые необходимо внести, см. в разделе ASP.NET 4 Child Applications Fail to Start When Under ASP.NET 2.0 or ASP.NET 3.5 Applications ("Дочерние приложения ASP.NET 4 не запускаются, если родительскими приложениями являются приложения ASP.NET 2.0 или ASP.NET 3.5") статьи ASP.NET 4 Breaking Changes ("Критические изменения в ASP.NET 4").
Изменения ClientID	Новый параметр `clientIDMode` в ASP.NET 4 позволяет задать способ создания платформой ASP.NET атрибута `id` для HTML-элементов. В более ранних версиях ASP.NET поведение по умолчанию соответствовало значению `AutoID` параметра `clientIDMode`. Теперь значение по умолчанию — `Predictable`. Дополнительные сведения см. в разделе Идентификация элементов управления Web Forms.	Если для обновления приложения с версии ASP.NET 2.0 или ASP.NET 3.5 используется Visual Studio, средство автоматически добавит в файл Web.config параметр, сохраняющий поведение предыдущих версий платформы .NET Framework. Однако если вы обновляете приложение путем изменения пула приложения в IIS, задавая .NET Framework 4 как целевую платформу, ASP.NET использует новый режим по умолчанию. Чтобы отключить новый режим идентификатора клиента, добавьте в файл Web.config следующий параметр: `<pages clientIDMode="AutoID" />`
Управление доступом для кода (CAS)	Функции NET ASP.NET 2.0, добавленные в ASP.NET 3.5, используют модель управления доступом для кода .NET Framework 1.1 и .NET Framework 2.0. Однако реализация управления доступом для кода в ASP.NET 4 значительно усовершенствована. В результате приложения ASP.NET с частичным доверием, которые зависят от выполнения доверенного кода в глобальном кэше сборок, могут давать сбой с различными исключениями безопасности. Приложения с частичным доверием, которые зависят от расширенных изменений в политике разграничения доступа кода компьютера, также могут давать сбои и создавать исключения безопасности.	Поведение приложений ASP.NET 4 с частичным доверием можно изменить на поведение версий ASP.NET 1.1 и 2.0, используя новый атрибут `legacyCasModel` в элементе конфигурации `trust`, как показано в следующем примере: `<trust level= "Medium" legacyCasModel="true" />` Внимание! Возврат к более старой модели управления доступом для кода может привести к снижению уровня безопасности. Дополнительные сведения о новой модели управления доступом для кода в ASP.NET 4 см. в разделе Управление доступом для кода для приложения ASP.NET 4.
Файлы конфигурации	Корневые файлы конфигурации (machine.config и корневой файл Web.config) для .NET Framework и 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. 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. Конкретное изменение, которое требуется внести, зависит от сочетания вашего программного обеспечения с учетом пакетов обновления. Сведения о возможных сочетаниях программного обеспечения, на которые влияет данное изменение, и о том, как разрешить проблемы, связанные с определенными сочетаниями, см. в разделе Configuration Errors Related to New ASP.NET 4 Root Configuration ("Ошибки конфигурации, связанные с новой корневой конфигурацией ASP.NET 4") статьи ASP.NET 4 Breaking Changes ("Критические изменения в ASP.NET 4").
Отрисовка элементов управления	В более ранних версиях ASP.NET некоторые элементы управления создавали разметку, которую нельзя было отключить. В ASP.NET 4 по умолчанию такой тип разметки больше не создается. Изменения касаются перечисленных ниже элементов управления. * Элементы управления `Image` и `ImageButton` больше не отрисовывают атрибут `border="0"`. * Класс `BaseValidator` и проверочные элементы управления, производные от него, по умолчанию больше не отрисовывают текст красного цвета. * Элемент управления `HtmlForm` не отрисовывает атрибут `name`. * Элемент управления `Table` больше не отрисовывает атрибут `border="0"`. Элементы управления, не предназначенные для пользовательского ввода (например, элемент управления `Label`), больше не отрисовывают атрибут `disabled="disabled"`, если свойство `Enabled` имеет значение `false` (или если этот параметр унаследован ими от контейнерного элемента управления).	Если вы используете Visual Studio для обновления своего приложения с версии ASP.NET 2.0 или ASP.NET 3.5, средство автоматически добавляет в файл Web.config параметр, сохраняющий традиционную отрисовку. Однако если вы обновляете приложение путем изменения пула приложений в IIS, задавая .NET Framework 4 как целевую платформу, ASP.NET использует новый режим отрисовки по умолчанию. Чтобы отключить новый режим отрисовки, добавьте в файл Web.config следующий параметр: `<pages controlRenderingCompatibilityVersion="3.5" />`
Обработчики событий в документах по умолчанию	ASP.NET 4 отображает значение атрибута `action` HTML-элемента `form` как пустую строку, когда запрос обращен к URL-адресу без расширения, с которым сопоставлен документ по умолчанию. В более ранних выпусках ASP.NET запрос к `http://contoso.com` привел бы к запросу к Default.aspx. В этом документе открывающий тег `form` отображался бы, как показано в следующем примере: `<form action="Default.aspx" />` В ASP.NET 4 запрос к `http://contoso.com` также приводит к запросу к Default.aspx, но ASP.NET теперь отображает открывающий HTML-тег `form`, как показано в следующем примере: `<form action="" />` Когда атрибут `action` является пустой строкой, объект `DefaultDocumentModule` служб IIS создает дочерний запрос к Default.aspx. В большинстве случаев этот дочерний запрос прозрачен для кода приложения и страница Default.aspx запускается нормально. Однако возможное взаимодействие между управляемым кодом и интегрированным режимом IIS 7 или IIS 7.5 может привести к тому, что управляемые ASPX-страницы перестанут работать корректно во время выполнения дочернего запроса. При выполнении описанных ниже условий дочерний запрос к ASPX-документу по умолчанию приведет к ошибке или неожиданному поведению. * На ASPX-странице, отправляемой браузеру, атрибут `action` элемента `form` имеет значение "". * Форма отправляется обратно платформе ASP.NET. * Управляемый HTTP-модуль считывает некоторую часть тела сущности, например `Request.Form` или `Request.Params`. Это приводит к тому, что тело сущности запроса POST считывается в управляемую память. В результате тело сущности становится недоступным для модулей машинного кода, запущенных в интегрированном режиме IIS 7 или IIS 7.5. * Объект `DefaultDocumentModule` служб IIS со временем выполняется и создает дочерний запрос к документу Default.aspx. Однако так как тело сущности уже было считано частью управляемого кода, тело сущности для отправки в дочерний запрос отсутствует. * При выполнении HTTP-конвейера для дочернего запроса обработчик ASPX-файлов запускается на этапе выполнения обработчика. Так как тела сущности нет, нет и переменных формы и состояния просмотра. Поэтому нет информации, позволяющей обработчику ASPX-страницы определить, какое событие должно вызываться (если такое событие имеется). В результате для соответствующей ASPX-страницы ни один из обработчиков событий обратной передачи не выполняется.	Сведения о том, как обойти проблемы, которые могут возникнуть в результате этого изменения, см. в разделе Event Handlers Might Not Be Not Raised in a Default Document in IIS 7 or IIS 7.5 Integrated Mode ("Обработчики событий могут не вызываться в документе по умолчанию в интегрированном режиме IIS 7 или IIS 7.5") статьи ASP.NET 4 Breaking Changes ("Критические изменения в ASP.NET 4").
Алгоритм хэширования	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" />`
Размещение элементов управления в Internet Explorer	Вы больше не можете размещать элементы управления Windows Forms в Интернете Обозреватель, так как существуют лучшие решения для размещения элементов управления в Интернете. Поэтому сборки IEHost.dll и IEExec.exe удалены из платформы .NET Framework.	Для разработки пользовательских элементов управления в веб-приложениях можно использовать указанные ниже технологии. * Можно создать приложение Silverlight и настроить его для работы вне браузера. Дополнительные сведения см. в разделе Out-of-Browser Support ("Поддержка вне браузера"). * Можно создать XAML-приложение браузера (XBAP), чтобы воспользоваться возможностями WPF (на клиентских компьютерах должна быть установлена платформа .NET Framework). Дополнительные сведения см. в разделе Общие сведения о приложениях браузера WPF XAML.
Методы HtmlEncode и UrlEncode	Методы `HtmlEncode` и `UrlEncode` классов HttpUtility и HttpServerUtility обновлены и теперь кодируют символ одинарной кавычки (') указанным ниже образом. * Метод `HtmlEncode` кодирует экземпляры одинарной кавычки как `'`. * Метод `UrlEncode` кодирует экземпляры одинарной кавычки как `%27`.	Просмотрите в коде места, где используются методы `HtmlEncode` и `UrlEncode`, и убедитесь в том, что изменение кодирования не повлияет на ваше приложение.
Ошибки HttpException в приложениях ASP.NET 2.0	После включения 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 4 не требуется для работы веб-сайта, измените сопоставление сайта для использования ASP.NET 2.0. –или– * Если ASP.NET 4 требуется для запуска веб-сайта, переместите любые дочерние виртуальные каталоги ASP.NET 2.0 на другой веб-сайт, который сопоставлен с ASP.NET 2.0. –или– * Отключите URL-адреса без расширений. Дополнительные сведения см. в разделе ASP.NET 2.0 Applications Might Generate HttpException Errors That Reference eurl.axd ("Приложения ASP.NET 2.0 могут вызывать ошибки HttpException, в которых указывается eurl.axd") статьи ASP.NET 4 Breaking Changes ("Критические изменения в ASP.NET 4").
Типы членства	Некоторые типы (например, MembershipProvider), используемые в членстве ASP.NET, перемещены из сборки System.Web.dll в сборку System.Web.ApplicationServices.dll. Типы были перемещены для устранения проблемы зависимостей уровней архитектуры между типами в клиенте и в расширенных SKU платформы .NET Framework.	Библиотеки классов, обновленные с предыдущих версий ASP.NET и использующие перемещенные типы членства, могут не компилироваться при использовании в проекте ASP.NET 4. В этом случае добавьте в сборку System.Web.ApplicationServices.dll ссылку из проекта библиотеки классов.
Изменения в элементе управления Menu	Изменения, внесенные в элемент управления Menu, приводят к описанному ниже поведению. * Если для MenuRenderingMode задано значение `List` или для MenuRenderingMode задано значение `Default` и для ControlRenderingCompatibilityVersion — значение `4.0` или выше, свойство PopOutImageUrl не действует. * Если путь, заданный в StaticPopOutImageUrl свойствах, DynamicPopOutImageUrl содержит обратную косую черту (\), изображения не отображаются. (В предыдущих версиях ASP.NET путь мог содержать обратную косую черту.)	* Вместо задания свойства PopOutImageUrl для отдельных пунктов меню задайте свойство StaticPopOutImageUrl или DynamicPopOutImageUrl родительского элемента управления Menu. –или– Для MenuRenderingMode задайте значение `Table` либо для MenuRenderingMode задайте значение `Default` и для ControlRenderingCompatibilityVersion — значение `3.5`. Эти параметры предписывают элементу управления Menu использовать структуру на основе таблицы HTML, которую он использовал в предыдущих версиях ASP.NET. * Если путь в StaticPopOutImageUrl свойстве содержит DynamicPopOutImageUrl обратную косую черту (\), замените символ косой черты (/).
Мобильная сборка в файле Web.config	В предыдущих версиях ASP.NET ссылка на сборку System.Web.Mobile.dll была включена в корневой файл Web.config раздела `assemblies` в `system.web`/`compilation`. Для повышения производительности ссылка на эту сборку удалена. Примечание. Сборка System.Web.Mobile.dll и мобильные элементы управления ASP.NET включены в ASP.NET 4, но использовать их не рекомендуется.	Если требуется использовать типы из этой сборки, добавьте ссылку на нее в корневой файл Web.config или в файл Web.config приложения.
Кэширование выходных данных	В ASP.NET 1.0 ошибка вызвала кэшированные страницы, указанные `Location="ServerAndClient"` в качестве параметра кэша"кэша", чтобы вывести `Vary:` заголовок HTTP в ответе. Таким образом, клиентские браузеры получали указание никогда не кэшировать такую страницу локально. В ASP.NET 1.1 был добавлен метод SetOmitVaryStar, который можно было вызвать для подавления заголовка `Vary:`. Однако отчеты об ошибках позволяют предположить, что разработчики не знают о поведении метода `SetOmitVaryStar`. В ASP.NET 4 HTTP-заголовок `Vary:` больше не создается для ответов, задающих следующую директиву: `<%@ OutputCache Location="ServerAndClient" %>` Поэтому метод SetOmitVaryStar больше не требуется для подавления заголовка `Vary:`. В приложениях, в которых атрибут `Location` имеет значение ServerAndClient, страницы можно будет кэшировать в браузере, не вызывая метод SetOmitVaryStar.	Если страницы в приложении должны создавать заголовок `Vary:`, следует вызвать метод AppendHeader, как показано в следующем примере: `System.Web.HttpResponse.AppendHeader("Vary","");` Кроме того, можно изменить значение атрибута `Location` кэширования выходных данных на Server.
Разбор страниц	Анализатор веб-страниц ASP.NET (ASPX-файлов) и пользовательских элементов управления (ASCX-файлов) в ASP.NET 4 работает строже, чем в предыдущих версиях ASP.NET, и помечает флагом недопустимости больше разметки, чем в предыдущих версиях.	Проанализируйте сообщения об ошибках, появляющиеся при выполнении страницы, и исправьте ошибки, возникающие из-за недопустимой разметки.
Типы Passport	Поддержка Passport, встроенная в ASP.NET 2.0, устарела и теперь не обеспечивается из-за изменений в службе Passport (теперь используется пакет SDK Live ID). Поэтому типы, связанные со службой Passport в пространстве имен System.Web.Security, теперь помечены атрибутом `ObsoleteAttribute`.	Измените код, в котором используются типы Passport в пространстве имен System.Web.Security (например, PassportIdentity), так, чтобы в нем использовался пакет SDK Windows Live ID.
Сведения PathInfo в свойстве FilePath	ASP.NET 4 больше не включает значение `PathInfo` в возвращаемые значения таких свойств, как FilePath, AppRelativeCurrentExecutionFilePath и CurrentExecutionFilePath. Вместо этого сведения `PathInfo` доступны в свойстве PathInfo. Рассмотрим следующий фрагмент URL-адреса: `/testapp/Action.mvc/SomeAction` В более ранних версиях ASP.NET свойства HttpRequest имели бы следующие значения: * FilePath: `/testapp/Action.mvc/SomeAction` * PathInfo: (пусто) В ASP.NET 4 свойства HttpRequest вместо этого имеют следующие значения: * FilePath: `/testapp/Action.mvc` * PathInfo: `SomeAction`	Найдите места в коде, где для получения сведений о пути используются свойства класса HttpRequest. Измените код в соответствии с изменением способа получения сведений о пути.
Проверка запросов	Чтобы улучшить проверку запросов, проверка запроса ASP.NET теперь вызывается раньше в жизненном цикле запроса. В результате проверка запросов выполняется для запросов, предназначенных не для ASPX-файлов, а, например, для вызовов веб-служб и для пользовательских обработчиков. Проверка запросов также будет активна при выполнении пользовательских HTTP-модулей в конвейере обработки запросов. В результате этого изменения запросы ресурсов, отличных от ASPX-файлов, могут приводить к ошибкам проверки запросов. Выполнение пользовательского кода в конвейере запросов (например, пользовательских HTTP-модулей) также может приводить к ошибкам проверки запросов.	Если необходимо, чтобы проверка запроса выполнялась только для ASPX-страниц, можно вернуться к старому поведению, задав в файле веб-конфигурации следующий параметр: `<httpRuntime requestValidationMode="2.0" />` Предупреждение. Если вы отменить изменения старое поведение, убедитесь, что весь код в существующих обработчиках, модулях и другом пользовательском коде выполняет проверка для потенциально небезопасных входных данных HTTP, которые могут быть векторами атак XSS.
Маршрутизация	Если вы создаете веб-сайт на базе файловой системы в Visual Studio 2010 и он находится в папке, в имени которой есть точка (.), маршрутизация URL-адресов не будет работать надежно. От некоторых виртуальных путей будет возвращаться ошибка HTTP 404. Причина в том, что Visual Studio 2010 запускает сервер Visual Studio Development Server, используя неправильный путь к корневому виртуальному каталогу.	* На странице Свойства веб-сайта на базе файловой системы измените значение атрибута Виртуальный путь на "/". –или– * Создайте проект веб-приложения вместо проекта веб-сайта. В проектах веб-приложений такой проблемы не существует, и маршрутизация URL-адресов работает, даже если в имени папки проекта есть точка. –или– * Создайте веб-сайт на базе HTTP, размещенный в IIS. Веб-сайты, размещенные в IIS, могут содержать точки в виртуальном пути и в имени папки файла проекта.
Сайты SharePoint	При попытке запустить веб-сайт ASP.NET 4, который развернут как дочерний элемент веб-сайта SharePoint, содержащего настраиваемый уровень частичного доверия с именем `WSS_Minimal`, появляется следующее сообщение об ошибке: `Could not find permission set named 'ASP.Net'.`	В настоящее время нет версий SharePoint, совместимых с ASP.NET. Поэтому не следует пытаться запустить веб-сайт ASP.NET 4 как дочерний элемент веб-сайта SharePoint.
Стандарты XHTML 1.1	Чтобы обеспечить соответствие стандартам XHTML 1.1 для новых веб-сайтов, элементы управления ASP.NET в .NET Framework 4 создают код HTML, соответствующий XHTML 1.1. Такая отрисовка включается следующим параметром в элементе `<system.Web>` файла Web.config: `<pages controlRenderingCompatibilityVersion="4.0"/>` По умолчанию параметр имеет значение 4.0. В веб-проектах, обновленных от Visual Studio 2008 до более новой версии, этот параметр имеет значение 3.5 для совместимости.	Нет.

Основные сведения