Dotnet что это за папка в windows 10

Параметры запуска приложения

При запуске приложения в dotnet доступны следующие параметры. Например, dotnet —roll-forward Major myapp.dll .

• —additionalprobingpath Путь, содержащий политику проверки и проверяемые сборки. Повторите этот параметр, чтобы указать несколько путей.
• —additional-deps Путь к дополнительному файлу .deps.json. Файл deps.json содержит список зависимостей, зависимости компиляции и сведения о версии, используемые для устранения конфликтов сборок. Дополнительные сведения см. в разделе Файлы конфигурации среды выполнения на GitHub.

• —roll-forward Управляет применением наката к приложению. SETTING может иметь одно из следующих значений. Если тип не указан, по умолчанию используется вариант Minor .
  • LatestPatch — накат до версии с наибольшим номером исправления. Отключает накат дополнительных версий.
  • Minor — накат до дополнительной версии со следующим по порядку возрастания номером, если запрошенная дополнительная версия отсутствует. Если запрошенная дополнительная версия присутствует, используется политика LatestPatch.
  • Major — накат до основной версии со следующим по порядку возрастания или дополнительной версии с наименьшим номером, если запрошенная дополнительная версия отсутствует. Если запрошенная основная версия присутствует, используется политика Minor.
  • LatestMinor — накат до дополнительной версии с наибольшим номером, даже если запрошенная дополнительная версия присутствует. Предназначен для сценариев размещения компонентов.
  • LatestMajor — накат до основной версии с наибольшим номером и дополнительной версии с наибольшим номером, даже если запрошенная основная версия присутствует. Предназначен для сценариев размещения компонентов.
  • Disable — накат не выполняется. Привязка только к указанной версии. Эта политика не рекомендуется для общего использования, поскольку отключает возможность наката до последних исправлений. Это значение рекомендуется использовать только для тестирования.

  Все параметры, кроме параметра Disable , будут использовать версию с последним доступным исправлением.

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

  Параметры запуска приложения с exec помощью команды

  Следующие параметры доступны только при dotnet запуске приложения с помощью exec команды . Например, dotnet exec —runtimeconfig myapp.runtimeconfig.json myapp.dll .

  • —depsfile Путь к файлу deps.json. Файл конфигурации deps.json содержит информацию о зависимостях, необходимых для выполнения приложения. Этот файл создается пакетом SDK для .NET.
  • —runtimeconfig Путь к файлу runtimeconfig.json. Файл runtimeconfig.json содержит параметры времени выполнения и обычно называется . Дополнительные сведения см. в статье Параметры конфигурации среды выполнения .NET.

  Команды dotnet

  Общее

  Команда	Функция
  dotnet build	Выполняет сборку приложения .NET.
  dotnet build-server	Взаимодействует с серверами, запущенными сборкой.
  dotnet clean	Очищает выходные данные сборки.
  dotnet exec	Запускает приложение .NET.
  dotnet help	Выводит более подробную документацию из Интернета для команды.
  dotnet migrate	Переносит допустимый проект предварительной версии 2 в проект пакета SDK .NET Core 1.0.
  dotnet msbuild	Обеспечивает доступ к командной строке MSBuild.
  dotnet new	Инициализирует проект C# или F# для заданного шаблона.
  dotnet pack	Создает пакет NuGet с кодом.
  dotnet publish	Публикует платформозависимое или автономное приложение .NET.
  dotnet restore	Восстанавливает зависимости для данного приложения.
  dotnet run	Запускает приложение из источника.
  dotnet sdk check	Отображает актуальное состояние установленного пакета SDK и версий среды выполнения.
  dotnet sln	Параметры для добавления, удаления и перечисления проектов в файле решения.
  dotnet store	Сохраняет сборки в хранилище пакетов среды выполнения.
  dotnet test	Выполняет тесты с помощью средства запуска тестов.

  Ссылки на проекты

  Команда	Функция
  dotnet add reference	Добавляет ссылку на проект.
  dotnet list reference	Перечисляет ссылки на проекты.
  dotnet remove reference	Удаляет ссылку на проект.

  Пакеты NuGet

  Команда	Функция
  dotnet add package	Добавляет пакет NuGet.
  dotnet remove package	Удаляет пакет NuGet.

  Команды NuGet

  Команда	Функция
  dotnet nuget delete	Удаляет пакет с сервера или из списка.
  dotnet nuget push	Отправляет пакет на сервер и публикует его.
  dotnet nuget locals	Очищает или перечисляет локальные ресурсы NuGet в кэше HTTP-запросов, временном кэше или папке пакетов, используемой на уровне компьютера.
  dotnet nuget add source	Добавляет источник NuGet.
  dotnet nuget disable source	Отключает источник NuGet.
  dotnet nuget enable source	Включает источник NuGet.
  dotnet nuget list source	Перечисляет все настроенные источники NuGet.
  dotnet nuget remove source	Удаляет источник NuGet.
  dotnet nuget update source	Обновляет источник NuGet.

  Команды рабочей нагрузки

  Команда	Функция
  dotnet workload install	Устанавливает дополнительную рабочую нагрузку.
  dotnet workload list	Выводит список установленных рабочих нагрузок.
  dotnet workload repair	Восстанавливает все установленные рабочие нагрузки.
  dotnet workload search	Вывод списка выбранных рабочих нагрузок или всех доступных рабочих нагрузок.
  dotnet workload uninstall	Удаляет рабочую нагрузку.
  dotnet workload update	Переустанавливает все установленные рабочие нагрузки.

  Команды глобального, установочного и локального средства

  Средства — это консольные приложения, которые устанавливаются из пакетов NuGet и вызываются из командной строки. Вы можете писать средства самостоятельно или устанавливать средства, написанные другими. Средства также называются глобальными средствами, средствами пути к средству и локальными средствами. Дополнительные сведения см. в обзоре средств .NET.

  Команда	Функция
  dotnet tool install	Устанавливает средство на компьютере.
  dotnet tool list	Выводит все глобальные, установочные и локальные средства, установленные на компьютере.
  dotnet tool search	Ищет в NuGet.org средства, в названии или метаданных которых есть указанный поисковый запрос.
  dotnet tool uninstall	Удаляет средство с компьютера.
  dotnet tool update	Обновляет средство, установленное на компьютере.

  Дополнительные средства

  В составе пакета SDK для .NET доступны следующие дополнительные средства:

  Средство	Функция
  dev-certs	Создает сертификаты разработки и управляет ими.
  ef	Средства командной строки для Entity Framework Core.
  user-secrets	Управляет секретами пользователей для разработки.
  watch	Наблюдатель за файлами, который перезапускает или перезагружает приложение при обнаружении изменений в исходном коде.

  Дополнительные сведения о каждом средстве можно получить с помощью команды dotnet —help .

  Примеры

  Создание нового консольного приложения .NET:

  dotnet new console 

  Сборка проекта и его зависимостей в указанном каталоге:

  dotnet build 

  dotnet exec myapp.dll 

  dotnet myapp.dll 

  См. также

  • Переменные среды, используемые пакетом SDK для .NET, .NET CLI и средой выполнения .NET
  • Файлы конфигурации среды выполнения
  • Параметры конфигурации времени выполнения .NET

  Установка .NET в Windows

  В этой статье описано, как установить .NET в Windows. .NET состоит из среды выполнения и пакета SDK. Среда выполнения используется для запуска приложения .NET и может быть включена в приложение. Пакет SDK используется для создания приложений и библиотек .NET. Среда выполнения .NET всегда устанавливается вместе с пакетом SDK.

  Последняя версия .NET — 8.0.

  Существует два типа поддерживаемых выпусков: выпуски долгосрочной поддержки (LTS) и выпуски стандартной поддержки терминов (STS). Качество всех выпусков одинаково. Единственное различие заключается в продолжительности поддержки. Выпуски LTS получают бесплатную поддержку и исправления в течение трех лет. Выпуски STS получают бесплатную поддержку и исправления в течение 18 месяцев. Дополнительные сведения см. в статье о политике поддержки .NET.

  В следующей таблице перечислены сведения о состоянии поддержки каждой версии .NET (и .NET Core):

  ✔️ Поддерживается	❌ Не поддерживается
  8 (LTS)	5
  7 (STS)	3.1
  6 (LTS)	3.0
  2.1
  2.0
  1,1
  1.0

  Установка с помощью Диспетчер пакетов Windows (winget)

  Вы можете установить и управлять .NET через службу Диспетчер пакетов Windows с помощью средства winget. Дополнительные сведения об установке и использовании winget см. в разделе «Использование средства winget«.

  Если вы устанавливаете .NET на уровне системы, установите с правами администратора.

  Установка пакета SDK

  Пакет SDK для .NET позволяет разрабатывать приложения с помощью .NET. При установке пакета SDK для .NET не требуется устанавливать соответствующие среды выполнения. Чтобы установить пакет SDK для .NET, выполните приведенную ниже команду.

  winget install Microsoft.DotNet.SDK.8 

  Установка среды выполнения

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

  Включает среду выполнения .NET	Включает среду выполнения рабочего стола .NET	Включает ASP.NET базовую среду выполнения
  Среда выполнения .NET	Да	No	No
  Среда выполнения рабочего стола .NET	Да	Да	Нет
  ASP.NET базовая среда выполнения	No	No	Да

  В следующем списке содержатся сведения о каждой среде выполнения вместе с командами winget для их установки:

  Среда выполнения рабочего стола .NET Эта среда выполнения поддерживает приложения Windows Presentation Foundation (WPF) и Windows Forms, созданные с помощью .NET. Это не то же самое, что и платформа .NET Framework, который поставляется с Windows. Эта среда выполнения включает среду выполнения .NET, но не включает ASP.NET Core Runtime, которая должна быть установлена отдельно.

  winget install Microsoft.DotNet.DesktopRuntime.8 

  winget install Microsoft.DotNet.Runtime.8 

  winget install Microsoft.DotNet.AspNetCore.8 

  Вы можете установить предварительные версии среды выполнения, заменив номер версии, например 6 словом Preview . В следующем примере устанавливается предварительная версия среды выполнения рабочего стола .NET:

  winget install Microsoft.DotNet.DesktopRuntime.Preview 

  Установка вместе с Visual Studio Code

  Visual Studio Code — это эффективный и облегченный редактор исходного кода, который работает на компьютере. Visual Studio Code доступен для Windows, macOS и Linux.

  Хотя Visual Studio Code не поставляется с автоматическим установщиком .NET Core, таким как Visual Studio, добавление поддержки .NET Core не вызывает затруднений.

  1. Скачайте и установите Visual Studio Code.
  2. Скачайте и установите пакет SDK для .NET.
  3. Установите расширение C# из Marketplace для Visual Studio Code.

  Расширение C# для Visual Studio Code включает последнюю версию пакета SDK для .NET, и вам не нужно устанавливать среду выполнения .NET отдельно.

  Установка с помощью установщика Windows

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

  Включает среду выполнения .NET	Включает среду выполнения рабочего стола .NET	Включает ASP.NET базовую среду выполнения
  Среда выполнения .NET	Да	No	No
  Среда выполнения рабочего стола .NET	Да	Да	Нет
  ASP.NET базовая среда выполнения	No	No	Да

  Пакет SDK для .NET позволяет создавать приложения .NET и содержать все среды выполнения.

  Страница загрузки для .NET содержит исполняемые файлы установщика Windows.

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

  • /install
    Устанавливает .NET.
  • /quiet
    Предотвращает отображение любого пользовательского интерфейса и запросов.
  • /norestart
    Подавляет попытки перезапуска.

  dotnet-sdk-8.0.100-win-x64.exe /install /quiet /norestart 

  Установщик возвращает код выхода 0 для успешного выполнения и код выхода 3010, чтобы указать, что требуется перезапуск. Любое другое значение обычно является кодом ошибки.

  Установка с помощью функции автоматизации PowerShell

  Сценарии dotnet-install используются для автоматизации непрерывной интеграции и ее осуществления без прав администратора. Вы можете скачать сценарий со страницы справочника по сценариям dotnet-install.

  Сценарий по умолчанию используется для установки последней долгосрочной версии поддержки (LTS), которая является .NET 8. Вы можете выбрать конкретный выпуск, указав параметр Channel . Включите параметр Runtime для установки среды выполнения. В противном случае сценарий устанавливает пакет SDK.

  Следующая команда устанавливает среды выполнения Desktop и ASP.NET Core для обеспечения максимальной совместимости.

  dotnet-install.ps1 -Channel 8.0 -Runtime windowsdesktop dotnet-install.ps1 -Channel 8.0 -Runtime aspnetcore 

  Установите пакет SDK, опустив параметр -Runtime . Этот -Channel параметр устанавливается в этом примере STS , который устанавливает последнюю версию поддержки терминов «Стандартный», которая является .NET 7.

  dotnet-install.ps1 -Channel STS 

  Установка с помощью Visual Studio

  Если вы используете Visual Studio для разработки приложений .NET, в следующей таблице указана минимальная требуемая версия Visual Studio на основе целевой версии пакета SDK для .NET.

  Версия пакета SDK для .NET	Версия Visual Studio
  8	Visual Studio 2022 версии 17.8 или более поздней.
  7	Visual Studio 2022 версии 17.4 или выше.
  6	Visual Studio 2022 версии 17.0 или более поздней
  5	Visual Studio 2019 версии 16.8 или более поздней.
  3.1	Visual Studio 2019 версии 16.4 или более поздней.
  3.0	Visual Studio 2019 версии 16.3 или более поздней.
  2,2	Visual Studio 2017 версии 15.9 или более поздней.
  2.1	Visual Studio 2017 версии 15.7 или более поздней.

  Если среда Visual Studio уже установлена, вы можете проверить ее версию, выполнив указанные ниже действия.

  1. Откройте Visual Studio.
  2. Выберите Справка>О Microsoft Visual Studio.
  3. Считайте номер версии из диалогового окна О программе.

  Visual Studio может установить последнюю версию пакета SDK для .NET и среды выполнения .NET.

  Выбор рабочей нагрузки

  При установке или изменении Visual Studio выберите одну или несколько из следующих рабочих нагрузок в зависимости от типа создаваемого приложения:

  • рабочая нагрузка Кроссплатформенная разработка .NET Core в разделе Другие наборы инструментов;
  • рабочая нагрузка ASP.NET и разработка веб-приложений в разделе Веб-разработка и облако;
  • рабочая нагрузка Разработка для Azure в разделе Веб-разработка и облако;
  • рабочая нагрузка Разработка классических приложений .NET в разделе Классические и мобильные.

  

  Поддерживаемые выпуски

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

  Даты окончания жизненного цикла версий Windows 10 зависят от выпуска. В следующей таблице рассматриваются только выпуски Домашняя, Профессиональная, Pro для образовательных учреждений и Pro для рабочих станций. Дополнительные сведения см. в справочных материалах по жизненному циклу поддержки Windows.

  Символ + представляет минимальную версию.

  Операционная система	.NET 8	.NET 7	.NET 6
  Windows 11	✔️	✔️	✔️
  Windows Server 2022	✔️	✔️	✔️
  Windows Server, версия 1903 или более поздняя	✔️	✔️	✔️
  Windows 10 версии 1607 или более поздней	✔️	✔️	✔️
  Windows 8.1	❌	❌	✔️
  Windows 7 с пакетом обновления 1 (SP1), ESU	❌	❌	✔️
  Windows Server 2019 Windows Server 2016 Windows Server 2012 R2 Windows Server 2012	✔️	✔️	✔️
  Windows Server Core 2012 R2	✔️	✔️	✔️
  Windows Server Core 2012	✔️	✔️	✔️
  Nano Server, версия 1809 и выше	✔️	✔️	✔️
  Nano Server, версия 1803	❌	❌	❌

  Дополнительные сведения о поддерживаемых операционных системах, дистрибутивах и политике жизненного цикла .NET 8 см . в поддерживаемых версиях ОС .NET 8.

  Неподдерживаемые выпуски

  Следующие версии .NET больше не поддерживаются (❌).

  • .NET 5
  • .NET Core 3.1.
  • .NET Core 3.0
  • .NET Core 2.2
  • .NET Core 2.1
  • .NET Core 2.0;

  Проверка скачанных двоичных файлов

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

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

  

  С помощью PowerShell или командной строки можно проверить проверка sum файла, который вы скачали. Например, следующая команда сообщает проверка sum файла dotnet-sdk-8.0.100-win-x64.exe:

  > certutil -hashfile dotnet-sdk-8.0.100-win-x64.exe SHA512 SHA512 hash of dotnet-sdk-8.0.100-win-x64.exe: 248acec95b381e5302255310fb9396267fd74a4a2dc2c3a5989031969cb31f8270cbd14bda1bc0352ac90f8138bddad1a58e4af1e56cc4a1613b1cf2854b518e CertUtil: -hashfile command completed successfully. 

  > (Get-FileHash .\dotnet-sdk-8.0.100-win-x64.exe -Algorithm SHA512).Hash 248acec95b381e5302255310fb9396267fd74a4a2dc2c3a5989031969cb31f8270cbd14bda1bc0352ac90f8138bddad1a58e4af1e56cc4a1613b1cf2854b518e 

  Сравните проверка sum со значением, предоставленным сайтом скачивания.

  Проверка с помощью PowerShell и файла проверка sum

  Заметки о выпуске .NET содержат ссылку на файл проверка sum, который можно использовать для проверки скачаемого файла. Ниже описано, как скачать файл проверка sum и проверить двоичный файл установки .NET:

  

  1. Страница заметок о выпуске для .NET 8 на сайте GitHub https://github.com/dotnet/core/tree/main/release-notes/8.0 содержит раздел с именем «Выпуски«. Таблица в этом разделе ссылается на скачиваемые файлы и файлы проверка sum для каждого выпуска .NET 8:
  2. Выберите ссылку для скачаемой версии .NET. Предыдущий раздел использовал пакет SDK для .NET 8.0.100, который находится в выпуске .NET 8.0.0.

  Совет Если вы не уверены, какой выпуск .NET содержит файл проверка sum, изучите ссылки, пока не найдете его.

  

• На странице выпуска можно увидеть версию пакета SDK для .NET и .NET, а также ссылку на файл проверка sum:
• Скопируйте ссылку на файл проверка sum.
• Используйте следующий скрипт, но замените ссылку, чтобы скачать соответствующий файл проверка sum:

  Invoke-WebRequest https://dotnetcli.blob.core.windows.net/dotnet/checksums/8.0.0-sha.txt -OutFile 8.0.0-sha.txt 

  > (Get-Content .\8.0.0-sha.txt | Select-String "dotnet-sdk-8.0.100-win-x64.exe").Line -like (Get-FileHash .\dotnet-sdk-8.0.100-win-x64.exe -Algorithm SHA512).Hash + "*" True 

  Сведения о среде выполнения

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

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

  Включает среду выполнения .NET	Включает среду выполнения рабочего стола .NET	Включает ASP.NET базовую среду выполнения
  Среда выполнения .NET	Да	No	No
  Среда выполнения рабочего стола .NET	Да	Да	Нет
  ASP.NET базовая среда выполнения	No	No	Да

  В следующем списке содержатся сведения о каждой среде выполнения:

  • Среда выполнения рабочего стола
    Используется для запуска классических приложений .NET WPF и Windows Forms для Windows. Включает среду выполнения .NET.
  • ASP.NET базовая среда выполнения
    Используется для запуска приложений ASP.NET Core.
  • Среда выполнения .NET
    Простейшая среда выполнения, в состав которой не входят какие-либо другие среды выполнения. Установите ASP.NET Core Runtime и Desktop Runtime для обеспечения оптимальной совместимости с приложениями .NET.

  Сведения о пакете SDK

  Пакет SDK используется для создания и публикации приложений и библиотек .NET. Установка пакета SDK включает все три среды выполнения: ASP.NET Core, Desktop и .NET.

  Компьютеры Windows на базе ARM

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

  Поддерживаемые возможности

  В следующей таблице описаны версии .NET, поддерживаемые на компьютерах Windows на базе ARM:

  Версия .NET	Архитектура	SDK	Параметры выполнения	Конфликт путей
  8	Arm64	Да	Да	Нет
  8	x64	Да	Да	Нет
  7	Arm64	Да	Да	Нет
  7	x64	Да	Да	Нет
  6	Arm64	Да	Да	Нет
  6	x64	Да	Да	Нет
  5	Arm64	Да	Да	Да
  5	x64	No	Да	Да

  Версии пакета SDK для .NET 64 и Arm64 существуют независимо друг от друга. Если выпущена новая версия, необходимо обновить каждую установку архитектуры.

  Различия в путях

  На компьютере с Windows на основе Arm все версии Arm64 .NET устанавливаются в обычную папку C:\Program Files\dotnet\ . Однако версия пакета SDK для .NET установлена в папку C:\Program Files\dotnet\x64\.

  Конфликты путей

  Пакет SDK для x64 .NET устанавливается в собственный каталог, как описано в предыдущем разделе. Это позволяет существовать на одном компьютере версии пакета SDK для .NET для Arm64 и x64. Однако любой пакет SDK x64 до 6 не поддерживается и устанавливается в то же расположение, что и версия Arm64 , папка C:\Program Files\dotnet\ . Если вы хотите установить неподдерживаемый пакет SDK x64, сначала необходимо удалить версию Arm64. Наоборот, необходимо удалить неподдерживаемый пакет SDK x64 для установки версии Arm64.

  Переменные пути

  Переменные среды, добавляющие .NET в системный PATH путь, например переменную, могут быть изменены, если установлены версии пакета SDK для .NET для x64 и Arm64. Кроме того, некоторые средства полагаются на DOTNET_ROOT переменную среды, которая также должна быть обновлена, чтобы указать соответствующую папку установки пакета SDK для .NET.

  Зависимости

  В .NET 8 поддерживаются следующие версии Windows:

  Символ + представляет минимальную версию.

  ОС	Версия	Архитектуры
  Windows 11	22000+	x64, x86, ARM64
  Клиент Windows 10	1607+	x64, x86, ARM64
  Windows Server	2012+	x64, x86
  Windows Server Core	2012+	x64, x86
  Nano Server	1809+	x64

  Дополнительные сведения о поддерживаемых операционных системах, дистрибутивах и политике жизненного цикла .NET 8 см . в поддерживаемых версиях ОС .NET 8.

  В .NET 7 поддерживаются следующие версии Windows:

  Символ + представляет минимальную версию.

  ОС	Версия	Архитектуры
  Windows 11	21H2+	x64, ARM64
  Клиент Windows 10	1607+	x64, x86, ARM64
  Windows Server	2012+	x64, x86
  Windows Server Core	2012+	x64, x86
  Nano Server	1809+	x64

  Дополнительные сведения о поддерживаемых операционных системах, дистрибутивах и политике жизненного цикла .NET 7 см . в поддерживаемых версиях ОС .NET 7.

  .NET 6 поддерживает следующие версии Windows:

  Символ + представляет минимальную версию.

  ОС	Версия	Архитектуры
  Windows 11	21H2+	x64, ARM64
  Клиент Windows 10	1607+	x64, x86, ARM64
  Клиент Windows	7 с пакетом обновления 1 и более поздних версий (SP1+), 8.1	x64, x86
  Windows Server	2012+	x64, x86
  Windows Server Core	2012+	x64, x86
  Nano Server	1809+	x64

  Дополнительные сведения об операционных системах, дистрибутивах и политике жизненного цикла, поддерживаемых .NET 6, см. в статье Поддерживаемые .NET 6 версии ОС.

  Автономная установка для Windows 7

  Этот раздел относится только к .NET Core 2.1.

  При автономной установке для .NET Core 2.1 в Windows 7 убедитесь, что на целевом компьютере установлен последний корневой центр сертификации Майкрософт 2011 .

  Средство certmgr.exe позволяет автоматизировать установку сертификата и его получение из Visual Studio или Windows SDK. Следующая команда используется для установки сертификата перед запуском установщика платформы .NET Core 2.1:

  certmgr.exe /add MicRooCerAut2011_2011_03_22.crt /s /r localMachine root 

  Обязательно ознакомьтесь с зависимостями ниже, необходимыми для Windows 7.

  Windows 7 / 8.1 / Server 2012

  При установке пакета SDK для .NET или среды выполнения .NET в следующих версиях Windows требуются дополнительные зависимости:

  Операционная система	Необходимые компоненты
  Windows 7 с пакетом обновления 1 (SP1), ESU	– Распространяемый компонент Microsoft Visual C++ 2015–2019, 64-разрядный / 32-разрядный – Обновление KB3063858, 64-разрядное / 32-разрядное — Центр корневой сертификации Microsoft 2011 (только удаленный установщик .NET Core 2.1)
  Windows 8.1	Распространяемый компонент Microsoft Visual C++ 2015–2019, 64-разрядный / 32-разрядный
  Windows Server 2012	Распространяемый компонент Microsoft Visual C++ 2015–2019, 64-разрядный / 32-разрядный
  Windows Server 2012 R2	Распространяемый компонент Microsoft Visual C++ 2015–2019, 64-разрядный / 32-разрядный

  Приведенные выше требования также применяются, если возникает ошибка, связанная с любой из следующих библиотек DLL:

  • api-ms-win-crt-runtime-l1-1-0.dll
  • api-ms-win-cor-timezone-l1-1-0.dll
  • hostfxr.dll

  Docker

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

  .NET можно выполнять в контейнере Docker. Официальные образы Docker для .NET публикуются в реестре контейнеров Microsoft (MCR), и доступ к ним можно получить в репозитории Microsoft .NET Docker Hub. Каждый репозиторий содержит рабочие образы для разных сочетаний .NET (пакета SDK или среды выполнения) и операционной системы.

  Корпорация Майкрософт предоставляет образы, которые предназначены для конкретных сценариев. Например репозиторий ASP.NET Core содержит образы, которые предназначены для запуска приложений ASP.NET Core в рабочей среде.

  Дополнительные сведения об использовании .NET в контейнере Docker см. в статьях Введение в .NET и Docker и Примеры.

  Устранение неполадок

  После установки пакета SDK для .NET могут возникнуть проблемы, связанные с выполнением команд .NET CLI. В этом разделе собираются распространенные проблемы и предоставляются решения.

  Пакет SDK для .NET не найден

  Скорее всего, вы установили версии x86 (32-разрядная версия) и x64 (64-разрядная версия пакета SDK для .NET). Это приводит к конфликту, так как при выполнении dotnet команды она разрешается в версию x86, когда она должна разрешаться в версию x64. Обычно это исправлено путем настройки переменной %PATH% , чтобы сначала разрешить версию x64.

  Убедитесь, что установлены обе версии, выполнив where.exe dotnet команду. Если это сделать, вы увидите запись для папок Program Files\ и Program Files (x86)\ . Если папка Program Files (x86)\ является первой, как показано в следующем примере, это неправильно, и вы должны продолжить переход к следующему шагу.

  > where.exe dotnet C:\Program Files (x86)\dotnet\dotnet.exe C:\Program Files\dotnet\dotnet.exe 

  Если это правильно, и program Files\ первый, у вас нет проблемы, которую обсуждает этот раздел, и вы должны создать проблему с запросом справки .NET на GitHub

• Нажмите кнопку Windows и введите «Изменить системные переменные среды» в поиск. Выберите «Изменить системные переменные среды».
• Откроется окно «Свойства системы» на вкладке «Дополнительно». Выберите переменные среды.
• В окне «Переменные среды» в группе системных переменных выберите строку Path* и нажмите кнопку «Изменить«.
• Используйте кнопки перемещения вверх и вниз, чтобы переместить запись C:\Program Files\dotnet\ выше C:\Program Files (x86)\dotnet\.

Следующие шаги

• Проверка того, установлена ли платформа .NET.
• Руководство. Руководство по Hello World.
• Руководство. Создание приложения с помощью Visual Studio Code.
• Руководство. Контейнеризация приложения .NET Core.

Совместная работа с нами на GitHub

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

Форматы путей к файлам в системах Windows

Члены большинства типов в пространстве имен System.IO имеют параметр path , который позволяет указать абсолютный или относительный путь к ресурсу в файловой системе. Этот путь передается в API файловой системы Windows. В этом разделе рассматриваются форматы путей к файлам, которые можно использовать в операционных системах Windows.

Традиционные пути DOS

Стандартный путь DOS может состоять из трех компонентов:

• Буква тома или диска, после которой следует разделитель томов ( : ).
• Имя каталога. Символ разделителя каталогов служит для разделения подкаталогов во внутренней иерархии каталога.
• Необязательное имя файла. Символ разделителя каталогов служит для разделения пути к файлу и его имени.

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

Путь	Description
C:\Documents\Newsletters\Summer2018.pdf	Абсолютный путь к файлу из корня диска C: .
\Program Files\Custom Utilities\StringFinder.exe	Относительный путь от корня текущего диска.
2018\January.xlsx	Относительный путь к файлу в подкаталоге текущего каталога.
..\Publications\TravelBrochure.pdf	Относительный путь к файлу в каталоге, начиная с текущего каталога.
C:\Projects\apilibrary\apilibrary.sln	Абсолютный путь к файлу из корня диска C: .
C:Projects\apilibrary\apilibrary.sln	Относительный путь из текущего каталога диска C: .

Обратите внимание на различия между двумя последними путями. В обоих случаях задается необязательный описатель тома ( C: ), однако первый путь, в отличие от второго, начинается с корня указанного тома. В результате первый путь является абсолютным из корневого каталога диска C: , тогда как второй — относительным из текущего каталога C: . Использование второй формы пути в тех случаях, когда предполагается наличие первой, является распространенным источником ошибок, связанных с путями к файлам в Windows.

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

В приведенном ниже примере показано различие между абсолютными и относительными путями. Предполагается, что каталог D:\FY2018\ существует и вы не установили какой-либо текущий каталог для диска D:\ из командной строки перед запуском этого примера.

using System; using System.Diagnostics; using System.IO; using System.Reflection; public class Example < public static void Main(string[] args) < Console.WriteLine($"Current directory is ''"); Console.WriteLine("Setting current directory to 'C:\\'"); Directory.SetCurrentDirectory(@"C:\"); string path = Path.GetFullPath(@"D:\FY2018"); Console.WriteLine($"'D:\\FY2018' resolves to "); path = Path.GetFullPath(@"D:FY2018"); Console.WriteLine($"'D:FY2018' resolves to "); Console.WriteLine("Setting current directory to 'D:\\Docs'"); Directory.SetCurrentDirectory(@"D:\Docs"); path = Path.GetFullPath(@"D:\FY2018"); Console.WriteLine($"'D:\\FY2018' resolves to "); path = Path.GetFullPath(@"D:FY2018"); // This will be "D:\Docs\FY2018" as it happens to match the drive of the current directory Console.WriteLine($"'D:FY2018' resolves to "); Console.WriteLine("Setting current directory to 'C:\\'"); Directory.SetCurrentDirectory(@"C:\"); path = Path.GetFullPath(@"D:\FY2018"); Console.WriteLine($"'D:\\FY2018' resolves to "); // This will be either "D:\FY2018" or "D:\FY2018\FY2018" in the subprocess. In the sub process, // the command prompt set the current directory before launch of our application, which // sets a hidden environment variable that is considered. path = Path.GetFullPath(@"D:FY2018"); Console.WriteLine($"'D:FY2018' resolves to "); if (args.Length < 1) < Console.WriteLine(@"Launching again, after setting current directory to D:\FY2018"); Uri currentExe = new Uri(Assembly.GetExecutingAssembly().GetName().CodeBase, UriKind.Absolute); string commandLine = $"/C cd D:\\FY2018 & \"\" stop"; ProcessStartInfo psi = new ProcessStartInfo("cmd", commandLine); ; Process.Start(psi).WaitForExit(); Console.WriteLine("Sub process returned:"); path = Path.GetFullPath(@"D:\FY2018"); Console.WriteLine($"'D:\\FY2018' resolves to "); path = Path.GetFullPath(@"D:FY2018"); Console.WriteLine($"'D:FY2018' resolves to "); > Console.WriteLine("Press any key to continue. "); Console.ReadKey(); > > // The example displays the following output: // Current directory is 'C:\Programs\file-paths' // Setting current directory to 'C:\' // 'D:\FY2018' resolves to D:\FY2018 // 'D:FY2018' resolves to d:\FY2018 // Setting current directory to 'D:\Docs' // 'D:\FY2018' resolves to D:\FY2018 // 'D:FY2018' resolves to D:\Docs\FY2018 // Setting current directory to 'C:\' // 'D:\FY2018' resolves to D:\FY2018 // 'D:FY2018' resolves to d:\FY2018 // Launching again, after setting current directory to D:\FY2018 // Sub process returned: // 'D:\FY2018' resolves to D:\FY2018 // 'D:FY2018' resolves to d:\FY2018 // The subprocess displays the following output: // Current directory is 'C:\' // Setting current directory to 'C:\' // 'D:\FY2018' resolves to D:\FY2018 // 'D:FY2018' resolves to D:\FY2018\FY2018 // Setting current directory to 'D:\Docs' // 'D:\FY2018' resolves to D:\FY2018 // 'D:FY2018' resolves to D:\Docs\FY2018 // Setting current directory to 'C:\' // 'D:\FY2018' resolves to D:\FY2018 // 'D:FY2018' resolves to D:\FY2018\FY2018 

Imports System.Diagnostics Imports System.IO Imports System.Reflection Public Module Example Public Sub Main(args() As String) Console.WriteLine($"Current directory is ''") Console.WriteLine("Setting current directory to 'C:\'") Directory.SetCurrentDirectory("C:\") Dim filePath As String = Path.GetFullPath("D:\FY2018") Console.WriteLine($"'D:\\FY2018' resolves to ") filePath = Path.GetFullPath("D:FY2018") Console.WriteLine($"'D:FY2018' resolves to ") Console.WriteLine("Setting current directory to 'D:\\Docs'") Directory.SetCurrentDirectory("D:\Docs") filePath = Path.GetFullPath("D:\FY2018") Console.WriteLine($"'D:\\FY2018' resolves to ") filePath = Path.GetFullPath("D:FY2018") ' This will be "D:\Docs\FY2018" as it happens to match the drive of the current directory Console.WriteLine($"'D:FY2018' resolves to ") Console.WriteLine("Setting current directory to 'C:\\'") Directory.SetCurrentDirectory("C:\") filePath = Path.GetFullPath("D:\FY2018") Console.WriteLine($"'D:\\FY2018' resolves to ") ' This will be either "D:\FY2018" or "D:\FY2018\FY2018" in the subprocess. In the sub process, ' the command prompt set the current directory before launch of our application, which ' sets a hidden environment variable that is considered. filePath = Path.GetFullPath("D:FY2018") Console.WriteLine($"'D:FY2018' resolves to ") If args.Length < 1 Then Console.WriteLine("Launching again, after setting current directory to D:\FY2018") Dim currentExe As New Uri(Assembly.GetExecutingAssembly().GetName().CodeBase, UriKind.Absolute) Dim commandLine As String = $"/C cd D:\FY2018 & """" stop" Dim psi As New ProcessStartInfo("cmd", commandLine) Process.Start(psi).WaitForExit() Console.WriteLine("Sub process returned:") filePath = Path.GetFullPath("D:\FY2018") Console.WriteLine($"'D:\\FY2018' resolves to ") filePath = Path.GetFullPath("D:FY2018") Console.WriteLine($"'D:FY2018' resolves to ") End If Console.WriteLine("Press any key to continue. ") Console.ReadKey() End Sub End Module ' The example displays the following output: ' Current directory is 'C:\Programs\file-paths' ' Setting current directory to 'C:\' ' 'D:\FY2018' resolves to D:\FY2018 ' 'D:FY2018' resolves to d:\FY2018 ' Setting current directory to 'D:\Docs' ' 'D:\FY2018' resolves to D:\FY2018 ' 'D:FY2018' resolves to D:\Docs\FY2018 ' Setting current directory to 'C:\' ' 'D:\FY2018' resolves to D:\FY2018 ' 'D:FY2018' resolves to d:\FY2018 ' Launching again, after setting current directory to D:\FY2018 ' Sub process returned: ' 'D:\FY2018' resolves to D:\FY2018 ' 'D:FY2018' resolves to d:\FY2018 ' The subprocess displays the following output: ' Current directory is 'C:\' ' Setting current directory to 'C:\' ' 'D:\FY2018' resolves to D:\FY2018 ' 'D:FY2018' resolves to D:\FY2018\FY2018 ' Setting current directory to 'D:\Docs' ' 'D:\FY2018' resolves to D:\FY2018 ' 'D:FY2018' resolves to D:\Docs\FY2018 ' Setting current directory to 'C:\' ' 'D:\FY2018' resolves to D:\FY2018 ' 'D:FY2018' resolves to D:\FY2018\FY2018 

UNC-пути

UNC-пути (универсальное соглашение об именовании) используются для доступа к сетевым ресурсам и имеют следующий формат:

• Имя сервера или узла, которому предшествуют символы \\ . В качестве имени сервера может выступать имя компьютера NetBIOS, а также IP-адрес или полное доменное имя (поддерживаются адреса IPv4 и IPv6).
• Имя общего ресурса, которое отделяется от имени узла символами \ . Имя сервера и имя общего ресурса в совокупности образуют том.
• Имя каталога. Символ разделителя каталогов служит для разделения подкаталогов во внутренней иерархии каталога.
• Необязательное имя файла. Символ разделителя каталогов служит для разделения пути к файлу и его имени.

Ниже приводятся некоторые примеры UNC-путей:

Путь	Description
\\system07\C$\	Корневой каталог диска C: на компьютере system07 .
\\Server2\Share\Test\Foo.txt	Файл Foo.txt в тестовом каталоге тома \\Server2\Share .

UNC-пути всегда должны быть полными. Они могут включать сегменты с относительным путем к каталогу ( . и .. ), однако они должны быть частью полного пути. Использовать относительные пути можно только посредством сопоставления UNC-пути с буквой диска.

Пути к устройствам DOS

В операционной системе Windows используется унифицированная объектная модель, которая указывает на все ресурсы, включая файлы. Эти пути к объектам доступны из окна консоли и предоставляются на уровень Win32 с использованием специальной папки с символьными ссылками, с которыми сопоставляются устаревшие пути DOS и UNC. Доступ к этой специальной папке осуществляется с использованием синтаксиса пути к устройству DOS, который может иметь одну из приведенных ниже форм:

Помимо использования буквы диска, вы можете указать том с помощью его GUID. Синтаксис будет иметь вид:

Синтаксис пути к устройству DOS поддерживается в реализациях платформы .NET для ОС Windows, начиная с версий .NET Core 1.1 и .NET Framework 4.6.2.

Путь к устройству DOS состоит из следующих компонентов:

Описатель пути к устройству ( \\.\ или \\?\ ), который идентифицирует путь как путь к устройству DOS.

Примечание. Описатель \\?\ поддерживается во всех версиях .NET Core, в .NET 5 и более поздних версий, а также в .NET Framework, начиная с версии 4.6.2.

Пути к устройству DOS полностью соответствуют определению и не могут начинаться с относительного сегмента каталога ( . или .. ). Они никогда не задаются относительно текущего каталога.

Пример: способы задать ссылку на один и тот же файл

В следующем примере демонстрируются некоторые способы задать ссылку на файл с использованием API в пространстве имен System.IO. В этом примере создается экземпляр объекта FileInfo и используются его свойства Name и Length, чтобы отобразить имя и длину файла.

using System; using System.IO; class Program < static void Main() < string[] filenames = < @"c:\temp\test-file.txt", @"\\127.0.0.1\c$\temp\test-file.txt", @"\\LOCALHOST\c$\temp\test-file.txt", @"\\.\c:\temp\test-file.txt", @"\\?\c:\temp\test-file.txt", @"\\.\UNC\LOCALHOST\c$\temp\test-file.txt", @"\\127.0.0.1\c$\temp\test-file.txt" >; foreach (var filename in filenames) < FileInfo fi = new FileInfo(filename); Console.WriteLine($"file : bytes"); > > > // The example displays output like the following: // file test-file.txt: 22 bytes // file test-file.txt: 22 bytes // file test-file.txt: 22 bytes // file test-file.txt: 22 bytes // file test-file.txt: 22 bytes // file test-file.txt: 22 bytes // file test-file.txt: 22 bytes 

Imports System.IO Module Program Sub Main() Dim filenames() As String = < "c:\temp\test-file.txt", "\\127.0.0.1\c$\temp\test-file.txt", "\\LOCALHOST\c$\temp\test-file.txt", "\\.\c:\temp\test-file.txt", "\\?\c:\temp\test-file.txt", "\\.\UNC\LOCALHOST\c$\temp\test-file.txt", "\\127.0.0.1\c$\temp\test-file.txt">For Each filename In filenames Dim fi As New FileInfo(filename) Console.WriteLine($"file : bytes") Next End Sub End Module 

Нормализация путей

Практически все передаваемые в API Windows пути нормализуются. При нормализации в Windows выполняются следующие действия:

• Идентифицируется путь.
• Текущий каталог применяется к неполным (относительным) путям.
• Выполняется канонизация разделителей каталогов.
• Вычисляются относительные компоненты каталога ( . для текущего и .. для родительского каталога).
• Удаляются некоторые символы.

Нормализация осуществляется неявно, но при необходимости вы можете выполнить ее явно, вызвав метод Path.GetFullPath, который создает оболочку для вызова функции GetFullPathName(). Также можно вызвать функцию GetFullPathName() Windows напрямую с помощью P/Invoke.

Идентификация пути

На первом шаге процесса нормализации осуществляется идентификация типа пути. Пути могут относиться к одной из нескольких категорий:

• Пути к устройствам: начинаются с двух разделителей и знака вопроса или точки ( \\? или \\. ).
• UNC-пути: начинаются с двух разделителей без знака вопроса или точки.
• Полные пути DOS: начинаются с буквы диска, разделителя томов и компонентов ( C:\ ).
• Пути к устаревшим устройствам ( CON , LPT1 ).
• Пути относительно корня текущего диска: начинаются с одного разделителя компонентов ( \ ).
• Пути относительно текущего каталога указанного диска: начинаются с буквы диска и разделителя томов, но не содержат разделителя компонентов ( C: ).
• Пути относительно текущего каталога: начинаются с любых других символов ( temp\testfile.txt ).

Тип пути определяет, будет ли каким-либо образом применяться текущий каталог. Кроме того, от типа пути зависит применяемый корень.

Работа с устаревшими устройствами

Если путь указывает на устаревшее устройство DOS, например CON , COM1 или LPT1 , он преобразуется в путь к устройству путем добавления перед ним последовательности \\.\ и возвращается в таком виде.

Путь, который начинается с имени устаревшего устройства, всегда интерпретируется как путь к устаревшему устройству с помощью метода Path.GetFullPath(String). Например, путь к устройству DOS CON.TXT будет выглядеть как \\.\CON , а путь к устройству DOS COM1.TXT\file1.txt будет выглядеть как \\.\COM1 .

Применение текущего каталога

Если путь не является полным, система Windows применяет к нему текущий каталог. К UNC-путям и путям к устройствам текущий каталог не применяется. Также текущий каталог не применяется к полным путям к диску с разделителем C:\ .

Если путь начинается с одного разделителя компонентов, применяется диск текущего каталога. Например, для пути к файлу \utilities и текущего каталога C:\temp\ в результате нормализации будет получен путь C:\utilities .

Если путь начинается с буквы диска, разделителя томов и не содержит разделителя компонентов, применяется последний текущий каталог, установленный из командной оболочки. Если последний текущий каталог не был установлен, применяется диск сам по себе. Например, для пути D:sources , текущего каталога C:\Documents\ и последнего текущего каталога D:\sources\ на диске D: в результате будет получен путь D:\sources\sources . Пути, задаваемые относительно диска, являются распространенными источниками ошибок программ и логики скрипта. Предположение, что путь, начинающийся с буквы и двоеточия, не является относительным, очевидно неверно.

Если путь не начинается с разделителя, применяются текущий диск и текущий каталог. Например, для пути к файлу filecompare и текущего каталога C:\utilities\ в результате будет получен путь C:\utilities\filecompare\ .

Применение относительных путей в многопотоковых приложениях (то есть в большинстве приложений) сопряжено с определенными рисками, поскольку текущий каталог задается на уровне процесса. Таким образом, любой поток может в любое время изменить текущий каталог. Начиная с версии .NET Core 2.1, вы можете вызвать метод Path.GetFullPath(String, String) для получения абсолютного пути на основе относительного и базового (текущий каталог) путей, относительно которых требуется выполнить разрешение.

Канонизация разделителей

Все символы косой черты ( / ) преобразуются в стандартные разделители Windows, то есть символы обратной косой черты ( \ ). Если они присутствуют, последовательность символов косой черты после первых двух таких символов свертывается в один символ косой черты.

Вычисление относительных компонентов

При обработке пути выполняется вычисление любых его компонентов или сегментов, которые состоят из одной или двух точек ( . или .. ):

• Если обнаруживается одна точка, текущий сегмент удаляется, поскольку он ссылается на текущий каталог.
• Если обнаруживаются две точки, удаляются текущий и родительский сегмент, поскольку в этом случае задается ссылка на родительский каталог. Родительские каталоги удаляются только в том случае, если они не находятся после корня пути. Корень пути зависит от его типа. Это будет диск ( C:\ ) для путей DOS, сервер или общий сетевой ресурс для UNC-путей ( \\Server\Share ) и префикс пути к устройству для путей к устройствам ( \\?\ или \\.\ ).

Удаление знаков

Помимо удаленных ранее разделителей и относительных сегментов во время нормализации также удаляются некоторые дополнительные знаки:

• Если сегмент заканчивается одной точкой, эта точка удаляется. (Сегмент одного или двойного периода нормализуется на предыдущем шаге. Сегмент из трех или более периодов не нормализован и фактически является допустимым именем файла или каталога.)
• Если путь не заканчивается разделителем, удаляются все конечные точки и пробелы (U+0020). Если последний сегмент содержит только одну или две точки, к нему применяется приведенное выше правило для относительных компонентов. Это правило устанавливает, что вы можете создать имя каталога с конечным пробелом, добавив разделитель после пробела.

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

Пропуск нормализации

Как правило, любой путь, передаваемый в API Windows передается в функцию GetFullPathName и нормализуется. Существует одно важное исключение: путь к устройству, который начинается со знака вопроса, а не с точки. Если путь не начинается с последовательности \\?\ (обратите внимание на использование канонической формы с обратной косой чертой), он нормализуется.

Зачем нужно пропускать нормализацию? Существует три основных причины:

1. Получение путей, которые в обычных обстоятельствах недоступны, но являются допустимыми. Например, невозможно каким-либо иным способом получить доступ к файлу или каталогу с именем hidden. .
2. Повышение производительности за счет пропуска нормализации в тех случаях, когда нормализация уже выполнена.
3. Только на платформе .NET Framework пропуск проверки длины пути MAX_PATH для использования путей длиной более 259 символов. Такое поведение допускается в большинстве API за некоторыми исключениями.

.NET Core и .NET 5 или более поздней версии обрабатывают длинные пути неявным образом и не выполняют проверку MAX_PATH . Проверка MAX_PATH применяется только для платформы .NET Framework.

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

Пути, начинающиеся с последовательности \\?\ , по-прежнему нормализуются, если явно передать их в функцию GetFullPathName.

Вы можете передавать пути длиной более MAX_PATH символов в функцию GetFullPathName без \\?\ . Она поддерживает пути произвольной длины, которая ограничивается лишь максимальным размером строки, поддерживаемым в Windows.

Регистр символов и файловая система Windows

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

Directory.Create("TeStDiReCtOrY"); 

Directory.Create("TeStDiReCtOrY") 

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

using System.IO; class Example < static void Main() < var fi = new FileInfo(@".\test.txt"); fi.MoveTo(@".\Test.txt"); >> 

Imports System.IO Module Example Public Sub Main() Dim fi As New FileInfo(".\test.txt") fi.MoveTo(".\Test.txt") End Sub End Module 

Тем не менее при сравнении имен каталогов и файлов регистр символов не учитывается. Если выполнить поиск файла с именем "test.txt", API файловой системы .NET будут игнорировать регистр символов при сравнении. Таким образом, при поиске файла "test.txt" будут возвращены совпадения для файлов "Test.txt", "TEST.TXT", "test.TXT", а также любых других их вариантов с различным сочетанием букв в верхнем и нижнем регистре.

Совместная работа с нами на GitHub

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

Удаление среды выполнения .NET и пакета SDK

По мере установки обновленных версий среды выполнения и пакета SDK .NET может потребоваться удалить устаревшие версии .NET с вашего компьютера. Удаление старых версий среды выполнения может изменить среду выполнения, выбранную для запуска приложений общей платформы, как описано в статье о выборе версии .NET.

Нужно ли удалять версию

Выбор версии .NET и совместимость среды выполнения .NET для различных обновлений обеспечивает безопасное удаление предыдущих версий. Обновления среды выполнения .NET совместимы в основной группе версий, например 7.x и 6.x. Кроме того, более поздние выпуски пакета SDK для .NET обычно позволяют создавать приложения, совместимые с предыдущими версиями среды выполнения.

Как правило, требуется только последняя версия пакета SDK и последняя версия исправлений для сред выполнения, необходимых для вашего приложения. Вы можете хранить старые пакеты SDK или версии среды выполнения, например для поддержки приложений на базе project.json. Если у приложения нет конкретных причин, по которым оно должно использовать ранние версии пакета SDK или среды выполнения, вы можете безопасно удалить старые версии.

Определите компоненты, которые нужно установить

Определить версии пакета SDK и среды выполнения, установленных на вашем компьютере, можно с помощью команд в .NET CLI. Используйте dotnet --list-sdks , чтобы просмотреть список установленных пакетов SDK, и dotnet --list-runtimes для просмотра списка сред выполнения. Дополнительные сведения см. в статье Проверка того, установлена ли платформа .NET.

Удаление .NET

Для удаления версий среды выполнения и пакета SDK .NET используется диалоговое окно Программы и компоненты Windows. На рисунке ниже показано диалоговое окно Программы и компоненты. Вы можете выполнить поиск по запросу core или .net, чтобы отфильтровать и вывести установленные версии .NET.



Выберите все версии, которые необходимо удалить с компьютера, и нажмите кнопку Удалить.

Лучший способ удаления .NET — выполнить действие, противоположное тому, которое использовалось при установке .NET. Конкретные действия зависят от выбранного дистрибутива Linux и метода установки.

Предварительные версии устанавливаются вручную и должны быть удалены вручную. Дополнительные сведения см. в разделе "Скрипты" или "Вручную ".

Дополнительные сведения об установке Red Hat см. в документации по Red Hat для .NET.

При установке .NET можно удалить следующие типы:

• Диспетчер пакетов
• Установка вручную или скриптов

Диспетчер пакетов

Нет необходимости сначала удалять пакет SDK для .NET при его обновлении с помощью диспетчера пакетов, если только не выполняется обновление с предварительной версии, установленной вручную. Диспетчер пакетов update или команды refresh автоматически удалят старую версию после успешной установки более новой версии. Если у вас установлена предварительная версия, удалите ее.

Если вы установили .NET с помощью диспетчера пакетов, для удаления пакета SDK для .NET или среды выполнения используется тот же диспетчер пакетов. .NET поддерживает большинство популярных менеджеров пакетов. Точный синтаксис команды для вашей среды см. в документации по вашему дистрибутиву:

• apt-get(8) используется в системах на основе Debian, включая Ubuntu.
• yum(8) используется в Fedora, CentOS, Oracle Linux и RHEL.
• zypper(8) используется в openSUSE и SUSE Linux Enterprise System (SLES).
• dnf(8) используется в Fedora.

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

Для установки пакета SDK для .NET в большинстве диспетчеров пакетов используется имя пакета dotnet-sdk , за которым следует номер версии. Начиная с версии 2.1.300 пакета SDK для .NET и версии 2.1 среды выполнения необходимы только основной номер версии и дополнительный номер версии: например, для версии 2.1.300 пакета SDK для .NET можно указать пакет dotnet-sdk-2.1 . В предыдущих версиях необходимо указать полную строку версии, например, для версии 2.1.200 пакета SDK для .NET потребовалось бы указать dotnet-sdk-2.1.200 .

Для компьютеров, на которых установлена только среда выполнения без пакета SDK, используется имя пакета dotnet-runtime- для среды выполнения .NET и aspnetcore-runtime- для стека всей среды выполнения.

Скрипты или вручную

Если вы установили .NET с помощью скрипта dotnet-install или извлекаете tarball, необходимо удалить .NET с помощью ручного метода.

При установке .NET вручную он обычно устанавливается в /usr/share/dotnet/ /usr/lib/dotnet/ каталог или $HOME/.dotnet каталог. Узел SDK, среды выполнения и .NET устанавливаются в отдельные вложенные каталоги. Эти каталоги component содержат каталог для каждой версии .NET. Удалив версии каталогов, вы удалите эту версию .NET из системы. Эти каталоги могут различаться в зависимости от дистрибутива Linux.

Существует три команды, которые можно использовать для обнаружения места установки .NET: dotnet --list-sdks для пакетов SDK, dotnet --list-runtimes для сред выполнения и dotnet --info для всего. Эти команды не перечисляют узел .NET. Чтобы определить, какие узлы установлены, проверка /usr/share/dotnet/host/fxr/ каталоге. Следующий список представляет каталоги определенной версии .NET, где $version переменная представляет версию .NET:

• Пакет SDK: /usr/share/dotnet/sdk/$version/
• Среда выполнения. Среда выполнения основана на конкретных средах выполнения продукта .NET, таких как Microsoft.AspNetCore.All или Microsoft.NETCore.App (среда выполнения .NET специально). Они устанавливаются в /usr/share/dotnet/shared/$product/$version каталог, где $product находится среда выполнения продукта. Например, могут отображаться следующие каталоги:

/usr/share/dotnet/shared/Microsoft.NETCore.App/$version/ /usr/share/dotnet/shared/Microsoft.AspNetCore.App/$version/ /usr/share/dotnet/shared/Microsoft.AspNetCore.All/$version/ 

rm -rf Используйте команду, чтобы удалить версию .NET. Например, чтобы удалить пакет SDK 6.0.406, выполните следующую команду:

sudo rm -rf /usr/share/dotnet/sdk/6.0.406 

Каталоги версий могут не совпадать с "версией", которую вы удаляете. Отдельные среды выполнения и пакеты SDK, установленные с одним выпуском .NET, могут иметь разные версии. Например, возможно, вы установили ASP.NET Core 8 Runtime, которая установила среду выполнения 8.0.2 ASP.NET Core и среду выполнения 8.0.8 .NET. У каждого из них есть другой каталог с версиями. Дополнительные сведения см. в статье Общие сведения об управлении версиями в .NET.

При установке .NET вручную он обычно устанавливается в /usr/local/share/dotnet/ каталог или $HOME/.dotnet каталог. Узел SDK, среды выполнения и .NET устанавливаются в отдельные вложенные каталоги. Эти каталоги component содержат каталог для каждой версии .NET. Удалив версии каталогов, вы удалите эту версию .NET из системы. Эти каталоги могут различаться в зависимости от дистрибутива Linux.

Существует три команды, которые можно использовать для обнаружения места установки .NET: dotnet --list-sdks для пакетов SDK, dotnet --list-runtimes для сред выполнения и dotnet --info для всего. Эти команды не перечисляют узел .NET. Чтобы определить, какие узлы установлены, проверка /usr/local/share/dotnet/host/fxr/ каталоге. Следующий список представляет каталоги определенной версии .NET, где $version переменная представляет версию .NET:

• Пакет SDK: /usr/local/share/dotnet/sdk/$version/
• Среда выполнения. Среда выполнения основана на конкретных средах выполнения продукта .NET, таких как Microsoft.AspNetCore.All или Microsoft.NETCore.App (среда выполнения .NET специально). Они устанавливаются в /usr/local/share/dotnet/shared/$product/$version каталог, где $product находится среда выполнения продукта. Например, можно увидеть следующие каталоги:

/usr/local/share/dotnet/shared/Microsoft.NETCore.App/$version/dotnet --info /usr/local/share/dotnet/shared/Microsoft.AspNetCore.App/$version/ /usr/local/share/dotnet/shared/Microsoft.AspNetCore.All/$version/ 

rm -rf Используйте команду, чтобы удалить версию .NET. Например, чтобы удалить пакет SDK 6.0.406, выполните следующую команду:

sudo rm -rf /usr/local/share/dotnet/sdk/6.0.406 

Каталоги версий могут не совпадать с "версией", которую вы удаляете. Отдельные среды выполнения и пакеты SDK, установленные с одним выпуском .NET, могут иметь разные версии. Например, возможно, вы установили ASP.NET Core 8 Runtime, которая установила среду выполнения 8.0.2 ASP.NET Core и среду выполнения 8.0.8 .NET. У каждого из них есть другой каталог с версиями. Дополнительные сведения см. в статье Общие сведения об управлении версиями в .NET.

Если вы используете Компьютер Mac на основе Arm, например один с микросхемой M1, просмотрите пути к каталогу, описанные в статье "Установка .NET на компьютерах Mac на основе Arm".

Средство удаления .NET

Средство удаления .NET ( dotnet-core-uninstall ) позволяет удалять пакеты SDK и среды выполнения .NET из системы. Указать удаляемые версии можно с помощью ряда параметров.

Зависимость Visual Studio от версий пакетов SDK для .NET

До появления Visual Studio 2019 версии 16.3 установщики Visual Studio пользовались автономным установщиком пакета SDK для .NET Core версий 2.1 или 2.2. В результате версии пакета SDK отображаются в диалоговом окне Windows Программы и компоненты. Удаление пакетов SDK для .NET, установленных Visual Studio с помощью автономного установщика, может нарушить работу Visual Studio. Если после удаления пакетов SDK в Visual Studio возникают проблемы, запустите "Восстановление" для этой конкретной версии Visual Studio. В следующей таблице показаны некоторые зависимости Visual Studio от пакета SDK для версий .NET Core.

Версия Visual Studio	Версия пакета SDK для .NET Core
Visual Studio 2019 версии 16.2	пакет SDK для NET Core 2.2.4xx, 2.1.8xx
Visual Studio 2019 версии 16.1	пакет SDK для .NET Core 2.2.3xx, 2.1.7xx
Visual Studio 2019 версии 16.0	пакет SDK для .NET Core 2.2.2xx, 2.1.6xx
Visual Studio 2017 версии 15.9	Пакет SDK для .NET Core 2.2.1xx, 2.1.5xx
Visual Studio 2017 версии 15.8	Пакет SDK для .NET Core 2.1.4xx

Visual Studio 2019 версии 16.3 и выше управляет собственной копией пакета SDK для .NET. По этой причине вы больше не встретите эти версии пакета SDK в диалоговом окне Программы и компоненты.

Удаление резервного каталога NuGet

Перед пакетом SDK для .NET Core 3.0 установщики пакета SDK для .NET Core использовали каталог NuGetFallbackFolder для хранения кэша пакетов NuGet. Этот кэш использовался во время таких операций, как dotnet restore или dotnet build /t:Restore . NuGetFallbackFolder находится в папке пакета SDK, в которой установлена .NET. Например, это может быть в C:\Program Files\dotnet\sdk\NuGetFallbackFolder в Windows и по адресу /usr/local/share/dotnet/sdk/NuGetFallbackFolder в macOS.

Возможно, вы хотите удалить этот каталог, если:

• Разработка выполняется только с использованием пакета SDK для .NET Core 3.0 или .NET 5 или более поздних версий.
• Разработка выполняется с использованием пакета SDK для .NET Core версий до 3.0, но вы можете работать в режиме "в сети".

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

Не рекомендуется удалять каталог dotnet . Это приведет к удалению всех ранее установленных глобальных средств. Также, в Windows:

• Работа Visual Studio 2019 версии 16.3 и более поздних версий будет нарушена. Для восстановления можно запустить Восстановление.
• Если в диалоговом окне Программы и компоненты есть записи пакета SDK для .NET Core, они будут потеряны.

Совместная работа с нами на GitHub

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

Похожие публикации:
1. Где в get запросе передать входные параметры
2. Где купить устройство для умного дома яндекса
3. Как отключить голосового помощника на телевизоре xiaomi mi
4. Как создать шаблон в ворде