Документация по .net

Приложение

Параметры командной строки

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

Параметр	Описание
/CEIPConsent	Перезаписывает поведение по умолчанию и отправляет анонимные сведения об установке в корпорацию Microsoft для совершенствования процедуры развертывания в будущем. Этот параметр можно использовать, только если программа установки запрашивает согласие пользователя и только если пользователь разрешает отправлять анонимную статистку в корпорацию Microsoft.
/chainingpackage	Указывает имя исполняемого файла, осуществляющего привязку. Эти сведения отправляются в корпорацию Microsoft в качестве анонимной статистики для совершенствования процедуры развертывания в будущем. Если в имени пакета присутствуют пробелы, в качестве разделителей необходимо использовать двойные кавычки (например, /chainingpackage «Lucerne Publishing» ). Пример привязываемого пакета см. в разделе Получение сведений о ходе выполнения из пакета установки.
/LCID где параметр задает код языка (список кодов см. на странице ).	Устанавливает языковой пакет, определенный параметром , и обеспечивает принудительное отображение пользовательского интерфейса на этом языке (если не включен автоматический режим). Для веб-установщика этот параметр обеспечивает установку (привязку) языкового пакета из Интернета. Примечание. Используйте этот параметр только с веб-установщиком.
/log |	Задает расположение файла журнала. Значение по умолчанию — временная папка для процесса, а имя файла по умолчанию основано на пакете. Если файл имеет расширение .txt, создается текстовый журнал. Если указано любое другое расширение или никакого расширения, создается журнал в формате HTML.
/msioptions	Задает параметры для передачи элементам MSI и MSP; например: .
/norestart	Запрещает программе установки автоматически перезагружать компьютер. При использовании этого параметра привязываемое приложение должно захватить код возврата и обработать перезагрузку (см. раздел Получение сведений о ходе выполнения из пакета установки).
/passive	Задает пассивный режим. Отображает индикатор выполнения, чтобы показать, что установка выполняется, но не выводит никаких приглашений и сообщений об ошибках. В этом режиме, при объединении в цепочку с программой установки, привязываемый пакет должен обрабатывать .
/pipe	Создает канал связи, чтобы привязываемый пакет мог получать информацию о ходе выполнения.
/promptrestart	Только пассивный режим; если программе установки необходима перезагрузка, она выводит соответствующий запрос для пользователя. При использовании этого параметра требуется вмешательство пользователя, если необходима перезагрузка.
/q	Включает автоматический режим.
/repair	Включение функции исправления.
/serialdownload	Обеспечивает, что установка происходит только после загрузки пакета.
/showfinalerror	Задает пассивный режим. Отображает ошибки только в том случае, если установка не выполнена успешно. При использовании этого параметра в случае ошибки установки требуется вмешательство пользователя.
/showrmui	Используется только с параметром /passive . Выводит окно сообщения, в котором пользователю предлагается закрыть работающие в данный момент приложения .NET Framework. Это окно сообщения ведет себя одинаково как в пассивном, так и не в пассивном режиме.
/uninstall	Удаляет распространяемый пакет .NET Framework.

Поддерживаемые языки

В приведенной ниже таблице перечислены языковые пакеты .NET Framework, доступные для платформы .NET Framework 4.5 и более поздних версий.

LCID	Язык — страна/регион	culture
1025	Арабский — Саудовская Аравия	ar
1028	Китайский (традиционное письмо)	zh-Hant
1029	Чешский	cs
1030	Датский	da
1031	Немецкий (Германия)	de
1032	Греческий	el
1035	Финский	fi
1036	Французский (Франция)	fr
1037	Иврит	he
1038	Венгерский	hu
1040	Итальянский (Италия)	it
1041	Японский	ja
1042	Корейский	ko
1043	Голландский (Нидерланды)	nl
1044	Норвежский (Букмол)	Нет
1045	Польский	pl
1046	Португальский (Бразилия)	pt-BR
1049	Русский	ru
1053	Шведский	sv
1055	Турецкий	tr
2052	Китайский (упрощенное письмо)	zh-Hans
2070	Португальский (Португалия)	pt-PT
3082	Испанский (Испания, современная сортировка)	es

Features of the common language runtime

The common language runtime manages memory, thread execution, code execution, code safety verification, compilation, and other system services. These features are intrinsic to the managed code that runs on the common language runtime.

Regarding security, managed components are awarded varying degrees of trust, depending on a number of factors that include their origin (such as the Internet, enterprise network, or local computer). This means that a managed component might or might not be able to perform file-access operations, registry-access operations, or other sensitive functions, even if it’s used in the same active app.

The runtime also enforces code robustness by implementing a strict type-and-code-verification infrastructure called the common type system (CTS). The CTS ensures that all managed code is self-describing. The various Microsoft and third-party language compilers generate managed code that conforms to the CTS. This means that managed code can consume other managed types and instances, while strictly enforcing type fidelity and type safety.

In addition, the managed environment of the runtime eliminates many common software issues. For example, the runtime automatically handles object layout and manages references to objects, releasing them when they are no longer being used. This automatic memory management resolves the two most common app errors, memory leaks and invalid memory references.

The runtime also accelerates developer productivity. For example, programmers write apps in their development language of choice yet take full advantage of the runtime, the class library, and components written in other languages by other developers. Any compiler vendor who chooses to target the runtime can do so. Language compilers that target the .NET Framework make the features of the .NET Framework available to existing code written in that language, greatly easing the migration process for existing apps.

While the runtime is designed for the software of the future, it also supports software of today and yesterday. Interoperability between managed and unmanaged code enables developers to continue to use necessary COM components and DLLs.

The runtime is designed to enhance performance. Although the common language runtime provides many standard runtime services, managed code is never interpreted. A feature called just-in-time (JIT) compiling enables all managed code to run in the native machine language of the system on which it’s executing. Meanwhile, the memory manager removes the possibilities of fragmented memory and increases memory locality-of-reference to further increase performance.

Finally, the runtime can be hosted by high-performance, server-side apps, such as Microsoft SQL Server and Internet Information Services (IIS). This infrastructure enables you to use managed code to write your business logic, while still enjoying the superior performance of the industry’s best enterprise servers that support runtime hosting.

Cross-platform

.NET (formerly known as .NET Core) is designed to be cross-platform. If your code doesn’t depend on Windows-specific technologies, it may run on other platforms such as macOS, Linux, and Android. This includes project types like:

• Libraries
• Console-based tools
• Automation
• ASP.NET sites

.NET Framework is a Windows-only component. When your code uses Windows-specific technologies or APIs, such as Windows Forms and Windows Presentation Foundation (WPF), the code can still run on .NET but it won’t run on other operating systems.

It’s possible that your library or console-based application can be used cross-platform without changing much. When porting to .NET, you may want to take this into consideration and test your application on other platforms.

Модели выполнения.

Приложения .NET запускают управляемый код в среде выполнения, известной как среда CLR.

CLR

.NET CLR — это кроссплатформенная среда выполнения, которая включает поддержку Windows, macOS и Linux. Среда CLR обрабатывает выделение памяти и управление ей. Среда CLR также является виртуальной машиной, которая не только выполняет приложения, но и создает, а также компилирует код с помощью JIT-компилятора.

Для получения дополнительной информации см. Common Language Runtime.

JIT-компилятор и промежуточный язык

Языки .NET более высокого уровня, например C#, компилируются до независимого от оборудования набора инструкций, который называется промежуточным языком (IL). При запуске приложений этот компилятор преобразует IL в машинный код, который понимает обработчик. JIT-компиляция происходит на том же компьютере, на котором будет выполняться код.

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

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

Дополнительные сведения см. в статьях Управляемый процесс выполнения и .

Компилятор AOT

По умолчанию большинство рабочих нагрузок .NET являются JIT-компилятором, но .NET предлагает две формы компиляции на момент времени (AOT):

• Для некоторых сценариев требуется 100-процентная компиляция AOT. Примером может служить iOS.
• В других сценариях большая часть кода приложения компилируется с помощью AOT, но для некоторых частей используется JIT-компилятор. Некоторые шаблоны кода не распознаются AOT (например, универсальные шаблоны). Примером такой формы компиляции AOT является параметр публикации . Такая форма AOT позволяет использовать преимущества компиляции без ее недостатков.

Автоматическое управление памятью

Сборщик мусора (GC) управляет выделением и освобождением памяти для приложений. Каждый раз, когда код создает новый объект, среда CLR выделяет память для объекта из . Пока в управляемой куче есть доступное адресное пространство, среда выполнения продолжает выделять пространство для новых объектов. Когда остается недостаточное свободное пространство адресов, сборщик мусора проверяет наличие объектов в управляемой куче, которые больше не используются приложением. Затем эта память освобождается.

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

Дополнительные сведения о сборке мусора см. в статьях Автоматическое управление памятью и Основы сборки мусора.

Работа с неуправляемыми ресурсами

Иногда код должен ссылаться на неуправляемые ресурсы. Неуправляемые ресурсы — это ресурсы, которые не обслуживаются средой выполнения .NET автоматически. Например, к неуправляемым ресурсам относятся дескрипторы файлов. Объект FileStream — управляемый, но он ссылается на дескриптор файла, который является неуправляемым ресурсом. После окончания работы с FileStream нужно явным образом освободить дескриптор файла.

В среде .NET объекты, которые ссылаются на неуправляемые ресурсы, реализуют интерфейс IDisposable. После окончания работы с объектом вызовите метод объекта, который отвечает за освобождение неуправляемых ресурсов. В языках .NET имеется удобная инструкция (C#, F#, VB), которая обеспечивает вызов метода .

Дополнительные сведения см. в разделе Очистка неуправляемых ресурсов.

When to choose .NET

The following sections give a more detailed explanation of the previously stated reasons for picking .NET over .NET Framework.

Cross-platform needs

If your web or service application needs to run on multiple platforms, for example, Windows, Linux, and macOS, use .NET.

.NET supports the previously mentioned operating systems as your development workstation. Visual Studio provides an Integrated Development Environment (IDE) for Windows and macOS. You can also use Visual Studio Code, which runs on macOS, Linux, and Windows. Visual Studio Code supports .NET, including IntelliSense and debugging. Most third-party editors, such as Sublime, Emacs, and VI, work with .NET. These third-party editors get editor IntelliSense using Omnisharp. You can also avoid any code editor and directly use the .NET CLI, available for all supported platforms.

Microservices architecture

A microservices architecture allows a mix of technologies across a service boundary. This technology mix enables a gradual embrace of .NET for new microservices that work with other microservices or services. For example, you can mix microservices or services developed with .NET Framework, Java, Ruby, or other monolithic technologies.

There are many infrastructure platforms available. Azure Service Fabric is designed for large and complex microservice systems. Azure App Service is a good choice for stateless microservices. Microservices alternatives based on Docker fit any kind of microservices approach, as explained in the section. All these platforms support .NET and make them ideal for hosting your microservices.

For more information about microservices architecture, see .NET Microservices. Architecture for Containerized .NET Applications.

Containers

Containers are commonly used in conjunction with a microservices architecture. Containers can also be used to containerize web apps or services that follow any architectural pattern. .NET Framework can be used on Windows containers, but the modularity and lightweight nature of .NET makes it a better choice for containers. When creating and deploying a container, the size of its image is much smaller with .NET than with .NET Framework. Because it’s cross-platform, you can deploy server apps to Linux Docker containers, for example.

Docker containers can be hosted in your own Linux or Windows infrastructure, or in a cloud service such as Azure Kubernetes Service. Azure Kubernetes Service can manage, orchestrate, and scale container-based applications in the cloud.

High-performance and scalable systems

When your system needs the best possible performance and scalability, .NET and ASP.NET Core are your best options. The high-performance server runtime for Windows Server and Linux makes ASP.NET Core a top performing web framework on .

Performance and scalability are especially relevant for microservices architectures, where hundreds of microservices may be running. With ASP.NET Core, systems run with a much lower number of servers/Virtual Machines (VM). The reduced servers/VMs save costs in infrastructure and hosting.

Side by side .NET versions per application level

To install applications with dependencies on different versions of .NET, we recommend .NET. This implementation supports side-by-side installation of different versions of the .NET runtime on the same machine. This side-by-side installation allows multiple services on the same server, each of them on its own version of .NET. It also lowers risks and saves money in application upgrades and IT operations.

Side-by-side installation isn’t possible with .NET Framework. It’s a Windows component, and only one version can exist on a machine at a time. Each version of .NET Framework replaces the previous version. If you install a new app that targets a later version of .NET Framework, you might break existing apps that run on the machine, because the previous version was replaced.

Considerations when porting

When porting your application to .NET, consider the following suggestions in order.

️ CONSIDER using the .NET Upgrade Assistant to migrate your projects. Even though this tool is in preview, it automates most of the manual steps detailed in this article and gives you a great starting point for continuing your migration path.

️ CONSIDER examining your dependencies first. Your dependencies must target .NET 5, .NET Standard, or .NET Core.

️ DO migrate from a NuGet packages.config file to PackageReference settings in the project file. Use Visual Studio to .

️ CONSIDER upgrading to the latest project file format even if you can’t yet port your app. .NET Framework projects use an outdated project format. Even though the latest project format, known as SDK-style projects, was created for .NET Core and beyond, they work with .NET Framework. Having your project file in the latest format gives you a good basis for porting your app in the future.

️ DO retarget your .NET Framework project to at least .NET Framework 4.7.2. This ensures the availability of the latest API alternatives for cases where .NET Standard doesn’t support existing APIs.

️ CONSIDER targeting .NET 5 instead of .NET Core 3.1. While .NET Core 3.1 is under long-term support (LTS), .NET 5 is the latest and .NET 6 will be LTS when released.

️ DO target .NET 5 for Windows Forms and WPF projects. .NET 5 contains many improvements for Desktop apps.

️ CONSIDER targeting .NET Standard 2.0 if you’re migrating a library that may also be used with .NET Framework projects. You can also multitarget your library, targeting both .NET Framework and .NET Standard.

️ DO add reference to the Microsoft.Windows.Compatibility NuGet package if, after migrating, you get errors of missing APIs. A large portion of the .NET Framework API surface is available to .NET via the NuGet package.

Дополнительная информация

Эти ошибки могут возникать при использовании мастера установки, средства системы обслуживания образов развертывания и управления ими (DISM) или команд Windows PowerShell для включения компонента .NET Framework 3.5.

В Windows 10, Windows Server 2012 R2 платформа .Net Framework 3.5 является компонентом, устанавливаемым по запросу. Метаданные для таких компонентов по запросу входят в систему. Однако двоичные и другие файлы, связанные с компонентом, — нет. При включении компонента Windows обращается к Центру обновления Windows для загрузки недостающей информации, необходимой для его установки. На этот процесс может повлиять конфигурация сети и настройка установки обновлений на компьютерах в данной среде. Поэтому при первой установке данных компонентов могут возникать ошибки.

Сообщения об ошибках, связанные с этими кодами ошибок

Код ошибки	Сообщения об ошибках
0x800F0906	Не удалось загрузить исходные файлы. Укажите расположение файлов, необходимых для восстановления компонента, с помощью параметра Источник. Для получения дополнительной информации об указании местоположения источника см. . Файл журнала DISM находится по адресу C:\Windows\Logs\DISM\dism.log. Windows не удалось применить требуемые изменения. Windows не удалось подключиться к Интернету, чтобы скачать необходимые файлы. Проверьте подключение и попробуйте еще раз, нажав кнопку Повторить. Сбой установки одной или нескольких ролей, служб ролей или компонентов. Не удалось найти исходные файлы. Попробуйте установить роли, службы ролей или компоненты еще раз в новом сеансе мастера добавления ролей и компонентов и выберите на странице подтверждения параметр Указать альтернативный исходный путь, чтобы указать действительное расположение исходных файлов, необходимых для установки. Расположение должно быть доступно для учетной записи компьютера конечного сервера. 0x800F0906 — CBS_E_DOWNLOAD_FAILURE Код ошибки: 0x800F0906 Ошибка: 0x800f0906
0x800F081F	Не удалось найти исходные файлы. Укажите расположение файлов, необходимых для восстановления компонента, с помощью параметра Источник. Для получения дополнительной информации об указании местоположения источника см. . Файл журнала DISM находится по адресу C:\Windows\Logs\DISM\dism.log 0x800F081F — CBS_E_SOURCE_MISSING Код ошибки: 0x800F081F Ошибка: 0x800F081F
0x800F0907	Сбой DISM. Операция не выполнена.Дополнительные сведения см. в файле журнала. Файл журнала DISM находится по адресу C:\Windows\Logs\DISM\dism.log Из-за параметров политики сети Windows не удалось подключиться к Интернету, чтобы скачать файлы, необходимые для выполнения запрошенных изменений. За дополнительными сведениями обратитесь к администратору сети. 0x800F0907 — CBS_E_GROUPPOLICY_DISALLOWED Код ошибки: 0x800F0907 Ошибка: 0x800F0907

Скачать .NET Framework 3.5 без обращения к Центру обновления Windows

Платформа .NET Framework 3.5 доступна для клиентов с корпоративным лицензированием или подпиской MSDN, поскольку им доступен носитель с компонентами по требованию.

Другие коды ошибок при установке платформы .NET Framework 3.5

При установке платформы .NET Framework 3.5 могут возникнуть другие коды ошибок, которые не указаны в данной статье базы знаний. Дополнительные сведения об этом см. в следующих статьях:

Supported client operating systems

Operating system	Supported editions	Preinstalled with the OS	Installable separately
Windows 11 (version 21H2)	64-bit	.NET Framework 4.8	—
Windows 10 May 2021 Update (version 21H1)	32-bit and 64-bit	.NET Framework 4.8	—
Windows 10 October 2020 Update (version 20H2)	32-bit and 64-bit	.NET Framework 4.8	—
Windows 10 May 2020 Update (version 2004)	32-bit and 64-bit	.NET Framework 4.8	—
Windows 10 November 2019 Update (version 1909)	32-bit and 64-bit	.NET Framework 4.8	—
Windows 10 May 2019 Update (version 1903)	32-bit and 64-bit	.NET Framework 4.8	—
Windows 10 October 2018 Update (version 1809)	32-bit and 64-bit	.NET Framework 4.7.2	.NET Framework 4.8
Windows 10 April 2018 Update (version 1803)	32-bit and 64-bit	.NET Framework 4.7.2	.NET Framework 4.8
Windows 10 Fall Creators Update (version 1709)	32-bit and 64-bit	.NET Framework 4.7.1	.NET Framework 4.7.2.NET Framework 4.8
Windows 10 Creators Update (version 1703)	32-bit and 64-bit	.NET Framework 4.7	.NET Framework 4.7.1.NET Framework 4.7.2.NET Framework 4.8
Windows 10 Anniversary Update (version 1607)	32-bit and 64-bit	.NET Framework 4.6.2	.NET Framework 4.7.NET Framework 4.7.1.NET Framework 4.7.2.NET Framework 4.8
Windows 10 November Update (version 1511)	32-bit and 64-bit	.NET Framework 4.6.1	.NET Framework 4.6.2
Windows 10 (version 1507)	32-bit and 64-bit	.NET Framework 4.6	.NET Framework 4.6.1 .NET Framework 4.6.2
Windows 8.1	32-bit, 64-bit, and ARM	.NET Framework 4.5.1	.NET Framework 4.5.2 .NET Framework 4.6 .NET Framework 4.6.1 .NET Framework 4.6.2.NET Framework 4.7.NET Framework 4.7.1.NET Framework 4.7.2.NET Framework 4.8
Windows 8	32-bit, 64-bit, and ARM	.NET Framework 4.5	.NET Framework 4.5.1.NET Framework 4.5.2 .NET Framework 4.6 .NET Framework 4.6.1
Windows 7 SP1	32-bit and 64-bit	—	.NET Framework 4 .NET Framework 4.5 .NET Framework 4.5.1 .NET Framework 4.5.2 .NET Framework 4.6 .NET Framework 4.6.1 .NET Framework 4.6.2.NET Framework 4.7.NET Framework 4.7.1.NET Framework 4.7.2.NET Framework 4.8
Windows Vista SP2	32-bit and 64-bit	—	.NET Framework 4 .NET Framework 4.5 .NET Framework 4.5.1 .NET Framework 4.5.2 .NET Framework 4.6
Windows XP	32-bit and 64-bit	—	.NET Framework 4

Notes:

• On Windows 7 systems, .NET Framework requires Windows 7 SP1. If you’re on Windows 7 and haven’t yet installed Service Pack 1, you need to do so before installing the .NET Framework.

• .NET Framework 4.5 is supported on the Windows Preinstallation Environment (Windows PE). Not all features are supported on Windows PE.

• .NET Framework 4 also supports the IA64 platform.

• For all platforms, we recommend that you upgrade to the latest Windows Service Pack and install critical updates available from Windows Update to ensure the best compatibility and security.

• On 64-bit operating systems, .NET Framework supports both WOW64 (32-bit processing on a 64-bit machine) and native 64-bit processing.

When to choose .NET Framework

.NET offers significant benefits for new applications and application patterns. However, .NET Framework continues to be the natural choice for many existing scenarios, and as such, .NET Framework isn’t replaced by .NET for all server applications.

Current .NET Framework applications

In most cases, you don’t need to migrate your existing applications to .NET. Instead, a recommended approach is to use .NET as you extend an existing application, such as writing a new web service in ASP.NET Core.

Third-party libraries or NuGet packages not available for .NET

.NET Standard enables sharing code across all .NET implementations, including .NET Core/5+. With .NET Standard 2.0, a compatibility mode allows .NET Standard and .NET projects to reference .NET Framework libraries. For more information, see .

You need to use .NET Framework only in cases where the libraries or NuGet packages use technologies that aren’t available in .NET Standard or .NET.

.NET Framework technologies not available for .NET

Some .NET Framework technologies aren’t available in .NET. The following list shows the most common technologies not found in .NET:

• ASP.NET Web Forms applications: ASP.NET Web Forms are only available in .NET Framework. ASP.NET Core cannot be used for ASP.NET Web Forms.

• ASP.NET Web Pages applications: ASP.NET Web Pages aren’t included in ASP.NET Core.

• WCF services implementation. Even when there’s a WCF client library to consume WCF services from .NET, WCF server implementation is currently only available in .NET Framework.

• Workflow-related services: Windows Workflow Foundation (WF), Workflow Services (WCF + WF in a single service), and WCF Data Services (formerly known as «ADO.NET Data Services») are only available in .NET Framework.

• Language support: Visual Basic and F# are currently supported in .NET, but not for all project types. For a list of supported project templates, see .

For more information, see .NET Framework technologies unavailable in .NET.

Platform doesn’t support .NET

Some Microsoft or third-party platforms don’t support .NET. Some Azure services provide an SDK not yet available for consumption on .NET. In such cases, you can use the equivalent REST API instead of the client SDK.

.NET Framework для пользователей

Если вы не разрабатываете приложения .NET Framework, но используете их, вам не требуется обладать специальными знаниями о платформе .NET Framework или ее работе. В большинстве случаев платформа .NET Framework совершенно прозрачна для пользователей.

Если используется операционная система Windows, платформа .NET Framework, возможно, уже установлена на компьютере. Кроме того, если устанавливается приложение, для работы которого требуется .NET Framework, программа установки приложения может установить нужную версию .NET Framework на компьютер. В некоторых случаях отображается диалоговое окно с приглашением установить платформу .NET Framework. Если вы попытались запустить приложение и появилось это окно, при наличии подключения к Интернету можно перейти на веб-страницу, откуда можно установить отсутствующую версию .NET Framework. Дополнительные сведения см. в руководстве по установке.

В общем случае не рекомендуется удалять версии платформы .NET Framework, установленные на компьютере. Для этого имеются две причины:

• Если приложение зависит от конкретной версии платформы .NET Framework, то при удалении этой версии его работа может быть нарушена.

• В некоторых версиях платформы .NET Framework существуют обновления на месте на более ранние версии. Например, .NET Framework 3.5 представляет собой обновление на месте для версии 2.0, а .NET Framework 4.8 — обновление на месте для версий с 4 по 4.7.2. Дополнительные сведения см. в разделе Платформа.NET Framework: версии и зависимости.

Если вы решите удалить платформу .NET Framework в версии Windows, предшествующей Windows 8, всегда используйте для удаления средство Программы и компоненты. Никогда не удаляйте версию платформы .NET Framework вручную. В ОС Windows 8 и более поздних версий .NET Framework представляет собой компонент операционной системы, который нельзя удалить отдельно.

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

Выберите и установите нужные Вам версии XP, 7, 8,10

Microsoft .NET Framework 1.0

Скачать Microsoft .NET Framework 1.0 для Windows 32/64 бит

Microsoft .NET Framework 1.1

Скачать Microsoft .NET Framework 1.1 для Windows 32/64 бит

Microsoft .NET Framework 2.0

Скачать Microsoft .NET Framework 2.0 для Windows 32 бит

Скачать Microsoft .NET Framework 2.0 для Windows 64 бит

Microsoft .NET Framework 3.0

Скачать Microsoft .NET Framework 3.0 для Windows 32/64 бит

Microsoft .NET Framework 3.5 (обязательная)

Скачать Microsoft .NET Framework 3.5 для Windows 32/64 бит

Microsoft .NET Framework 4.0

Скачать Microsoft .NET Framework 4.0 для Windows 32/64 бит

Microsoft .NET Framework 4.5

Скачать Microsoft .NET Framework 4.5 для Windows 32/64 бит

Microsoft .NET Framework 4.5.1

Скачать Microsoft .NET Framework 4.5.1 для Windows 32/64 бит

Microsoft .NET Framework 4.5.2

Скачать Microsoft .NET Framework 4.5.2 для Windows 32/64 бит

Microsoft .NET Framework 4.6

Скачать Microsoft .NET Framework 4.6 для Windows 32/64 бит

Microsoft .NET Framework 4.6.1

Скачать Microsoft .NET Framework 4.6.1 для Windows 32/64 бит

Microsoft .NET Framework 4.6.2

Скачать Microsoft .NET Framework 4.6.2 для Windows 32/64 бит

Microsoft .NET Framework 4.7

Скачать Microsoft .NET Framework 4.7 для Windows 32/64 бит

Microsoft .NET Framework 4.7.1

Скачать Microsoft .NET Framework 4.7.1 для Windows 32/64 бит

Microsoft .NET Framework 4.8

Скачать Microsoft .NET Framework 4.8 для Windows 32/64 бит

Microsoft .NET Framework 4 (веб-установщик, последняя версия, обязательная) 

Скачать Microsoft .NET Framework 4 для Windows 32/64 бит

Tools to assist porting

Instead of manually porting an application from .NET Framework to .NET, you can use different tools to help automate some aspects of the migration. Porting a complex project is, in itself, a complex process. These tools may help in that journey.

Even if you use a tool to help port your application, you should review the in this article.

.NET Upgrade Assistant

The .NET Upgrade Assistant is a command-line tool that can be run on different kinds of .NET Framework apps. It’s designed to assist with upgrading .NET Framework apps to .NET 5. After running the tool, in most cases the app will require more effort to complete the migration. The tool includes the installation of analyzers that can assist with completing the migration. This tool works on the following types of .NET Framework applications:

• Windows Forms
• WPF
• ASP.NET MVC
• Console
• Class libraries

This tool uses the other tools listed in this article and guides the migration process. For more information about the tool, see Overview of the .NET Upgrade Assistant.

try-convert

The try-convert tool is a .NET global tool that can convert a project or entire solution to the .NET SDK, including moving desktop apps to .NET 5. However, this tool isn’t recommended if your project has a complicated build process such as custom tasks, targets, or imports.

For more information, see the try-convert GitHub repository.

.NET Portability Analyzer

The .NET Portability Analyzer is a tool that analyzes assemblies and provides a detailed report on .NET APIs that are missing for the applications or libraries to be portable on your specified targeted .NET platforms.

To use the .NET Portability Analyzer in Visual Studio, install the extension from the marketplace.

For more information, see The .NET Portability Analyzer.

Platform compatibility analyzer

The Platform compatibility analyzer analyzes whether or not you’re using an API that will throw a PlatformNotSupportedException at run time. Although this isn’t common if you’re moving from .NET Framework 4.7.2 or higher, it’s good to check. For more information about APIs that throw exceptions on .NET, see APIs that always throw exceptions on .NET Core.

For more information, see Platform compatibility analyzer.

Распространяемые пакеты

Платформа .NET Framework доступна в виде двух распространяемых компонентов пакетов: веб-установщик (начальный загрузчик) и автономный установщик (автономный распространяемый компонент). Все файлы для скачивания .NET Framework размещаются на этой странице. В следующей таблице сравниваются два пакета:

	веб-установщик	автономный установщик
Требуется подключение к интернету?	Да	Нет
Размер загрузки	Меньший (включает только установщик для целевой платформы) *	Больший*
Языковые пакеты	Включены**	, если только не используется пакет, предназначенный для всех ОС
Метод развертывания	Поддерживает все методы:- — — — — —	Поддерживает все методы:- — — — — —

* Автономный установщик больше, так как он содержит компоненты для всех целевых платформ. По завершении работы программы установки операционная система Windows кэширует только использовавшийся установщик. Если удалить автономный установщик после установки, используемое место на диске будет таким же, как при использовании веб-установщика. Если средство, используемое для создания программы установки приложения (например, или ), предусматривает папку для файлов установки, которая удаляется после установки, автономный установщик может быть удален автоматически путем помещения его в папку установки.

**При использовании веб-установщика с пользовательской установкой можно использовать параметры языка по умолчанию на основе заданного пользователем параметра многоязычного пользовательского интерфейса (MUI) или задать другой языковой пакет с помощью параметра в командной строке. Примеры см. в подразделе .