Как перенацелить приложение visual studio

Общие сведения о настройке целевой платформы

Область применения:Visual Studio Visual Studio для Mac Visual Studio Code

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

Решение Visual Studio может содержать проекты, предназначенные для различных версий .NET. Обратите внимание, что вы можете выполнить сборку только для одной версии .NET с помощью условий ссылок для одной сборки или рекурсивно создавать разные двоичные файлы для каждой версии. Дополнительные сведения о требуемых версиях .NET Framework см. в разделе Целевые платформы.

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

Функции нацеливания на платформу

Среди прочего, доступны следующие возможности нацеливания на платформу:

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

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

• Он фильтрует элементы в диалоговом окне «Добавление нового элемента«, диалоговое окно «Добавить новую ссылку» и диалоговое окно «Добавить ссылку на службу», чтобы опустить варианты, недоступные в целевой версии.
• Он фильтрует пользовательские элементы управления на панели элементов , чтобы удалить те, которые недоступны в целевой версии, и показывать только самые актуальные элементы управления, если доступны несколько элементов управления.
• Фильтрует IntelliSense, чтобы пропустить языковые функции, которые недоступны в целевой версии.
• Фильтрует свойства в окне Свойства, чтобы пропустить те, которые недоступны в целевой версии.
• Фильтрует пункты меню, чтобы пропустить те, которые недоступны в целевой версии.
• Для сборок система использует версию и параметры компилятора, которые подходят для целевой версии.

• Нацеливание на платформу не гарантирует правильную работу приложения. Нужно протестировать приложение, чтобы убедиться в том, что оно работает с целевой версией.
• Ориентироваться на версии платформы, предшествующие .NET Framework 2.0, запрещено.

Выбор целевой версии платформы

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

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

Если вы решите создать проект .NET, то увидите интерфейс, похожий на тот, которой показан на двух следующих снимках экрана.

На первом экране вы увидите диалоговое окно Настройка нового проекта.

На втором экране появится диалоговое окно Дополнительные параметры.

Изменение требуемой версии .NET Framework

Для существующего проекта Visual Basic, C# или F# вы можете изменить целевую версию .NET в диалоговом окне свойств проекта. Сведения об изменении целевой версии для проектов C++ см. в статье How to: Modify the Target Framework and Platform Toolset (Практическое руководство. Изменение требуемой версии .NET Framework и набора средств платформы).

1. В обозревателе решений правой кнопкой мыши откройте контекстное меню проекта, в который необходимо внести изменения, и выберите Свойства.
2. В левом столбце окна Свойства перейдите на вкладку Приложение.

Примечание. После создания приложения UWP невозможно изменить целевую версию Windows или .NET.

1. В обозревателе решений правой кнопкой мыши откройте контекстное меню проекта, в который необходимо внести изменения, и выберите Свойства.
2. В левом столбце окна Свойства перейдите на вкладку Приложение.

Примечание. После создания приложения UWP невозможно изменить целевую версию Windows или .NET.

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

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

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

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

Разрешение системных ссылок и пользовательских ссылок на сборки

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

Для проектов платформа .NET Framework диалоговое окно «Добавить ссылку« отключает системные сборки, которые не относятся к целевой платформа .NET Framework версии, чтобы они не могли быть непреднамеренно добавлены в проект. (Системные сборки — это DLL-файлы, включенные в версию платформа .NET Framework.) Ссылки, принадлежащие версии платформы, которая выше целевой версии, не будут разрешаться, и элементы управления, зависящие от такой ссылки, не могут быть добавлены. Если вы хотите активировать такую ссылку, измените целевую версию платформы .NET Framework для проекта на ту, которая содержит эту ссылку.

Дополнительные сведения о ссылках на сборки см. в разделе Разрешение сборок во время разработки.

Включение LINQ

При нацеливании на .NET Framework 3.5 или более поздней версии ссылка на System.Core и импорт уровня проекта для System.Linq (только в Visual Basic) добавляются автоматически. Если вы хотите использовать функции LINQ, нужно также включить параметр Option Infer (только в Visual Basic). Ссылка и импорт удаляются автоматически при изменении целевой версии на более раннюю версию .NET Framework. Дополнительные сведения см. в разделе Работа с LINQ.

См. также

• Целевые платформы
• Многоплатформенное нацеливание (MSBuild)
• Практическое руководство. Изменение требуемой версии .NET Framework и набора средств платформы (C++)

Пример перехода на последнюю версию .NET

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

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

Миграция из .NET Core или .NET 5

Обновить приложения до последней версии .NET легко, если вы уже используете .NET Core или .NET 5. Если это так, в Visual Studio просто щелкните проект правой кнопкой мыши в Обозреватель решений и выберите «Свойства«. В разделе «Общая целевая>платформа приложений>» выберите .NET 7.0. Сохраните проект и выполните сборку приложения. Готово! Теперь приложение работает в последней версии .NET. В будущем, когда новые версии становятся доступными, вы можете обновить таким же образом.

Миграция из .NET Framework

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

Миграция с помощью средства

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

Миграция вручную

Процесс миграции состоит из четырех последовательных шагов:

1. Подготовка. Изучите зависимости, которые проект должен учитывать при дальнейших действиях. На этом шаге вы переведете текущий проект в состояние, которое упрощает точку запуска миграции.
2. Миграция файла проекта. В проектах .NET используется новый формат проекта в стиле пакета SDK. Создайте новый файл проекта с этим форматом или обновите его, чтобы использовать стиль пакета SDK.
3. Исправление кода и сборки. Создайте код в .NET для устранения различий на уровне API между платформой .NET Framework и .NET. При необходимости обновите сторонние пакеты до поддерживаемых версий .NET.
4. Запуск и тестирование. Могут возникнуть различия, которые не отображаются до времени выполнения. Поэтому не забудьте запустить приложение и проверить, чтобы все работало должным образом.

Подготовка

Миграция файла packages.config

В приложении .NET Framework все ссылки на внешние пакеты объявляются в файле packages.config. В .NET больше не нужно использовать файл packages.config. Вместо него используйте свойство PackageReference в файле проекта, чтобы указать пакеты NuGet для приложения.

Поэтому необходимо перейти от одного формата к другому. Обновление можно выполнить вручную, используя зависимости, содержащиеся в файле packages.config. Перенесите их в файл проекта в формате PackageReference . Вы также можете использовать Visual Studio: щелкните правой кнопкой мыши файл packages.config и выберите пункт Migrate packages.config to PackageReference (Перенос packages.config в PackageReference).

Проверка совместимости всех зависимостей в .NET

После переноса ссылок на пакеты необходимо проверить каждую ссылку на совместимость. Вы можете изучить зависимости каждого пакета NuGet, используемого в nuget.org. Если пакет имеет зависимости .NET Standard, он будет работать в .NET 7, так как .NET поддерживает все версии .NET Standard. На следующем изображении показаны зависимости для пакета Castle.Windsor :

Для проверки совместимости пакета можно использовать средство https://fuget.org, предоставляющее более подробные сведения о версиях и зависимостях.

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

Что, если вы не нашли совместимую версию? Что делать, если вы не хотите обновлять версию пакета из-за этих критических изменений? Не беспокойтесь, так как приложение .NET может зависеть от пакетов .NET Framework. Обязательно протестируйте сборку, так как она может вызвать ошибки во время выполнения, если внешний пакет вызывает API, недоступный в .NET. Это отлично подходит, если вы используете старый пакет, который не будет обновляться, и вы можете просто перенацелить работу в .NET.

Проверка на совместимость API

Так как поверхность API в платформах .NET Framework и .NET похожа, но не идентична, необходимо проверить, какие интерфейсы API доступны в .NET, а какие нет. Средство «Анализатор переносимости .NET» можно использовать для отображения API-интерфейсов, отсутствующих в .NET. Он смотрит на двоичный уровень приложения, извлекает все вызываемые API, а затем перечисляет, какие API недоступны в целевой платформе (.NET 7 в этом случае).

Дополнительные сведения об этом средстве можно найти по адресу:

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

Миграция

1. Создание проекта .NET

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

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

Рекомендации по AssemblyInfo

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

  false   

Ресурсы

Внедренные ресурсы включаются автоматически, но ресурсы — нет, поэтому ресурсы необходимо перенести в новый файл проекта.

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

С помощью параметра Migrate packages.config to PackageReference (Перенос packages.config в PackageReference) можно легко переместить ссылки на внешние пакеты в новый формат, как упоминалось ранее.

Обновление ссылок на пакеты

Обновите версии совместимых пакетов, как показано в предыдущем разделе.

Исправление кода и сборки

Microsoft.Windows.Compatibility

Если приложение зависит от API, которые недоступны в .NET, например реестра или списков управления доступом, необходимо включить ссылку на Microsoft.Windows.Compatibility пакет, чтобы добавить эти API для конкретного Windows. Они работают на платформе .NET, но не включены в нее, так как не являются кросс-платформенными.

Существует средство, именуемое анализатором совместимости платформы (https://learn.microsoft.com/dotnet/standard/analyzers/platform-compat-analyzer), помогающее определить интерфейсы API, которые не совместимы с кодом.

Использование директив #if

Если требуются разные пути выполнения при нацеливании на платформу .NET Framework и .NET, следует использовать константы компиляции. Добавьте в код некоторые директивы #if, чтобы сохранить одну и ту же базу кода для обоих целевых объектов.

Технологии, недоступные в .NET

Некоторые технологии недоступны в .NET, например:

• Домены приложений
• Удаленное взаимодействие
• Управление доступом для кода
• Рабочий процесс Windows

Именно поэтому необходимо найти замену этих технологий, если вы используете их в своем приложении. Дополнительные сведения см. в статье Технологии .NET Framework, недоступные в .NET Core и .NET 5 и более поздних версий.

Повторное создание автоматически созданных клиентов

Если приложение использует автоматически созданный код, например клиент WCF, может потребоваться повторно создать этот код для .NET. Иногда можно найти некоторые отсутствующие ссылки, так как они могут быть не включены в набор сборок .NET по умолчанию. С помощью такого средства как https://apisof.net/ можно легко найти сборку, в которой находится отсутствующая ссылка, и добавить ее из NuGet.

Откат версий пакета

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

Запуск и тестирование

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

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

Например, при использовании файлов конфигурации (app.config) могут возникнуть ошибки во время выполнения, например отсутствие разделов конфигурации. Использование пакета NuGet Microsoft.Extensions.Configuration должно исправить эту ошибку.

Другой причиной ошибок является использование методов BeginInvoke и EndInvoke , так как они не поддерживаются в .NET. Они не поддерживаются в .NET, так как имеют зависимость от удаленного взаимодействия, которое не существует в .NET. Чтобы решить эту проблему, попробуйте использовать ключевое слово await (если доступно) или метод Task.Run.

Анализаторы совместимости можно использовать для выявления интерфейсов API и шаблонов кода в коде, которые могут вызывать проблемы во время выполнения с помощью .NET. Перейдите на страницу https://github.com/dotnet/platform-compat и используйте анализатор API .NET для своего проекта.

Миграция приложения Windows Forms

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

Главное окно приложения можно увидеть на следующем изображении:

Открыв файл проекта .csproj, вы увидите примерно следующее:

Как и ранее упоминание, проект .NET имеет более компактный стиль и необходимо перенести структуру проекта в новый стиль пакета SDK для .NET.

В Обозреватель решений щелкните правой кнопкой мыши проект Windows Forms и выберите «Выгрузить >проект правки».

Теперь можно обновить файл .csproj. Вы удалите все содержимое и замените его следующим кодом:

  WinExe net7.0-windows true false   

Сохраните и перезагрузите проект. Теперь вы сделали обновление файла проекта, и проект предназначен для .NET 7.

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

Удалите файл Reference.cs и создайте клиент службы.

Щелкните правой кнопкой мыши Подключенные службы и выберите пункт Добавить подключенную службу.

Откроется окно «Подключенные службы». Выберите параметр Microsoft WCF Web Service.

Если у вас есть служба WCF в том же решении, что и в этом примере, вместо указания URL-адреса службы можно выбрать параметр Обнаружение.

После обнаружения службы средство отражает контракт API, реализованный службой. Измените имя пространства имен на eShopServiceReference , как показано на следующем изображении:

Нажмите кнопку Готово. Через некоторое время отобразится созданный код.

Вы должны увидеть три автоматически созданных файла:

1. Getting Started: ссылка на GitHub с информацией о WCF.
2. ConnectedService.json: параметры конфигурации для подключения к службе.
3. Reference.cs: фактический код клиента WCF.

При повторной компиляции отобразится множество ошибок, поступающих из файлов .cs в папку Helper. Эта папка присутствовала в версии .NET Framework, но не была включена в старую версию файла .csproj. Однако при использовании нового проекта в стиле пакета SDK каждый файл кода, который находится под расположением файла проекта, включается по умолчанию. То есть новый проект .NET Core пытается скомпилировать файлы в папке Helper. Так как эта папка не требуется, ее можно безопасно удалить.

Если скомпилировать проект еще раз и выполнить его, образы продукта не будут отображаться. Проблема заключается в том, что теперь путь к файлам немного изменился. Чтобы устранить эту проблему, добавьте в путь другой уровень глубины, обновив в файле CatalogView.cs строку:

string image_name = Environment.CurrentDirectory + "\\..\\..\\Assets\\Images\\Catalog\\" + catalogItems.Picturefilename; 

string image_name = Environment.CurrentDirectory + "\\..\\..\\..\\Assets\\Images\\Catalog\\" + catalogItems.Picturefilename; 

После этого изменения можно проверка, что приложение запускает и запускается должным образом в .NET 7.

Миграция приложения WPF

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

Это приложение использует локальную базу данных SQL Server Express для хранения сведений о каталоге продуктов. Доступ к этой базе данных осуществляется непосредственно из приложения WPF.

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

В этом случае удалите все содержимое файла .csproj и замените его следующим кодом:

   WinExe net7.0-windows true false   

Если перезагрузить проект и скомпилировать его, отобразится следующая ошибка:

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

Кроме того, для этого можно использовать Visual Studio, щелкнув правой кнопкой мыши узел Зависимости и выбрав пункт Добавить ссылку на проект. Выберите проект из решения и нажмите кнопку «ОК«:

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

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

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

The .NET documentation is open source. Provide feedback here.

Обратная связь

Отправить и просмотреть отзыв по

Перенаправление версий сборок

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

Эта статья посвящена платформа .NET Framework приложениям. Сведения о загрузке сборок в .NET 5+ (и .NET Core) см. в разделе Загрузка зависимостей в .NET.

Унификация сборок и привязка по умолчанию

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

Например, если приложение ссылается на типы в пространстве имен System.XML и было создано с помощью платформа .NET Framework 4.5, оно содержит статические ссылки на сборку System.XML, поставляемую со средой выполнения версии 4.5. Если вы хотите перенаправить ссылку на привязку, чтобы она указывала на сборку System.XML, поставляемую с платформа .NET Framework 4, можно поместить сведения о перенаправлении в файл конфигурации приложения. Перенаправление привязки в файле конфигурации для унифицированной сборки .NET Framework отменяет унификацию для этой сборки.

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

Перенаправление версий с помощью политики издателя

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

Каждая версия основной_номер.дополнительный_номер сборки имеет свой собственный файл политики издателя. Например, перенаправления от версии 2.0.2.222 к версии 2.0.3.000 и от версии 2.0.2.321 к версии 2.0.3.000 приводят к тому же файлу, поскольку они связаны с версией 2.0. Однако перенаправление от версии 3.0.0.999 к версии 4.0.0.000 приводит к файлу для версии 3.0.999. Каждая основная версия сборки .NET Framework имеет свой собственный файл политики издателя.

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

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

Перенаправление версий на уровне приложения

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

Изменение файла конфигурации приложения вручную

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

Использование автоматического перенаправления привязок

При создании классического приложения в Visual Studio, предназначенного платформа .NET Framework 4.5.1 или более поздней версии, приложение использует автоматическое перенаправление привязок. Это означает, что если два компонента ссылаются на разные версии одной сборки со строгим именем, среда выполнения автоматически добавляет в выходной файл конфигурации приложения (app.config) перенаправление привязки в новую версию сборки. Это перенаправление переопределяет унификацию сборок, которая может происходить в противном случае. Исходный файл app.config не изменяется. Например, предположим, что приложение непосредственно ссылается на компонент .NET Framework вне потока, но использует стороннюю библиотеку, которая нацелена на более старую версию того же компонента. При компиляции приложения выходной файл конфигурации приложения изменяется, и в него включается перенаправление привязки в новую версию компонента. Если вы создаете веб-приложение, то получите предупреждение о конфликте привязки, которое в свою очередь дает вам возможность добавить необходимое перенаправление привязки в исходный файл веб-конфигурации.

Если вы вручную добавите перенаправления привязки в файл исходного app.config, во время компиляции Visual Studio попытается объединить сборки на основе добавленных перенаправлений привязки. Например, предположим, что вы вставили следующее перенаправление привязки для сборки:

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

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

Обход политики издателя

При необходимости вы можете переопределить политику издателя в файле конфигурации приложения. Например, новые версии сборок, которые объявлены как поддерживающие обратную совместимость, могут все-таки нарушать работу приложения. Если вы хотите обойти политику издателя, добавьте в элемент dependentAssembly> в файле конфигурации приложения и задайте для атрибута apply значение нет, что переопределяет все предыдущие параметры «да».

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

Перенаправление версий на уровне компьютера

Иногда администратор компьютера хочет, чтобы все приложения на компьютере использовали определенную версию сборки. Например, определенная версия может устранить дыру в системе безопасности. Если сборка перенаправляется в файл конфигурации компьютера, который называется machine.config, все приложения на этом компьютере, использующие старую версию, направляются на использование новой версии. Файл конфигурации компьютера переопределяет файл конфигурации приложения и файл политики издателя. Этот machine.config файл находится в папке %windir%\Microsoft.NET\Framework[version]\config\machine.config для 32-разрядных компьютеров или %windir%\Microsoft.NET\Framework64[версия]\config\machine.config для 64-разрядных компьютеров.

Указание привязки сборки в файлах конфигурации

Этот же формат XML используется для указания перенаправлений привязки в файле конфигурации приложения, файле конфигурации компьютера или файле политики издателя. Чтобы перенаправить одну версию сборки в другую, используйте элемент bindingRedirect>. OldVersion можно указать одну версию сборки или диапазон версий. В атрибуте newVersion должна быть указана одна версия. Например, указывает, что среда выполнения должна использовать версию 2.0.0.0 вместо версий сборки от 1.1.0.0 до 1.2.0.0.

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

Чтобы привязать сборку, необходимо указать строку urn:schemas-microsoft-com:asm.v1 с атрибутом xmlns в теге .

Ограничение привязок сборок до определенной версии

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

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

Например, чтобы перенаправить одну ссылку на сборку .NET Framework 3.5, а другую ссылку — на сборку .NET Framework 4, можно использовать шаблон, показанный в следующем псевдокоде.

См. также

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

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

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

The .NET documentation is open source. Provide feedback here.

Обратная связь

Отправить и просмотреть отзыв по

Как перенацелить приложение visual studio

Для создания графических приложений на C# можно использовать .NET CLI, но также можно использовать бесплатную и полнофункциональную среду разработки — Visual Studio Community 2022 , которая в ряде случаев облегчает проектирование приложения. Так, загрузим установщик Visual Studio по адресу: https://www.visualstudio.com/en-us/downloads.

Чтобы добавить в Visual Studio поддержку проектов для Windows Forms и C# и .NET 7, в программе установки среди рабочих нагрузок нужно выбрать только пункт Разработка классических приложений .NET . Можно выбрать и больше опций или вообще все опции, однако стоит учитывать свободный размер на жестком диске — чем больше опций будет выбрано, соответственно тем больше места на диске будет занято.

После установки среды и всех ее компонентов, запустим Visual Studio и создадим проект графического приложения. На стартовом экране выберем Create a new project (Создать новый проект)

На следующем окне в качестве типа проекта выберем Windows Forms App :

Стоит отметить, что среди шаблонов можно увидеть еще тип Windows Forms App (.NET Framework) — его НЕ надо выбирать, необходим именно тип Windows Forms App .

Далее на следующем этапе нам будет предложено указать имя проекта и каталог, где будет располагаться проект.

В поле Project Name дадим проекту какое-либо название. В моем случае это HelloApp .

На следующем окне Visual Studio предложит нам выбрать версию .NET, которая будет использоваться для проекта. Выберем последнюю на данный момент версию — .NET 7.0 и нажмен на кнопку Create (Создать) для создания проекта.

После этого Visual Studio откроет наш проект с созданными по умолчанию файлами:

Справа находится окно Solution Explorer, в котором можно увидеть структуру нашего проекта. Практически этот тот же проект, который создается с помощью .NET CLI:

• Dependencies — это узел содержит сборки dll, которые добавлены в проект по умолчанию. Эти сборки как раз содержат классы библиотеки .NET, которые будет использовать C#
• Form1.Designer.cs : он содержит определение компонентов формы, добавленных на форму в графическом дизайнере
• Далее идет файл единственной в проекте формы — Form1.cs , который по умолчанию открыт в центральном окне.
• Program.cs определяет точку входа в приложение

Запуск приложения

Чтобы запустить приложение в режиме отладки, нажмем на клавишу F5 или на зеленую стрелочку на панели Visual Studio.

После этого запустится пустая форма Form1 по умолчанию.

После запуска приложения студия компилирует его в файл с расширением exe. Найти данный файл можно, зайдя в папку проекта и далее в каталог \bin\Debug\net7.0-windows

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