Как предотвратить ошибку app.config после переноса на .Net Core приложения с app.config и файлом .settings?

Я столкнулся с проблемой при переносе некоторых наших проектов .Net Framework на .Net Core. После переноса, если в проекте есть файл app.config И файл Settings.settings, я получаю сообщение об ошибке каждый раз, когда открываю проект или просматриваю свойства проекта.

После некоторого расследования мне удалось воспроизвести проблему без переноса — просто создав приложение .Net Core Windows Forms, а затем добавив app.config и settings.settings следующим образом:

Использование Visual Studio 2019 версии 16.7.3 (ошибка также возникает в более ранних версиях):

  1. Создайте новый проект Приложение Windows Forms (.Net Core) .Net Core 3.1.
  2. В среде IDE щелкните правой кнопкой мыши проект в Обозревателе решений и выберите Добавить | Новый элемент...
  3. Выберите файл конфигурации приложения и нажмите «Добавить».
  4. Перейдите в раздел Свойства проекта и перейдите на вкладку Настройки.
  5. Нажмите Этот проект не содержит файла настроек по умолчанию. Нажмите здесь, чтобы создать его.
  6. Добавьте строковую пользовательскую настройку с именем Setting со значением test.
  7. Построить приложение.
  8. Закройте все окна проекта.
  9. Перейдите в «Свойства проекта» и перейдите на вкладку «Настройки».

В этот момент я вижу ошибку:

Произошла ошибка при чтении файла app.config. Файл может быть поврежден или содержать недопустимый XML.

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

Как я могу предотвратить появление этой ошибки, кроме удаления App.Config?

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


[EDIT] Я отправил это в Microsoft как ошибку здесь: https://github.com/dotnet/sdk/issues/13478


person Matthew Watson    schedule 09.09.2020    source источник
comment
это может помочь: stackoverflow.com/questions/ 45034007/ и docs.microsoft.com/ en-us/dotnet/core/run-time-config   -  person Kixoka    schedule 09.09.2020
comment
@Kixoka Первый из них устарел, а второй не актуален, потому что они предполагают, что Settings.settings не поддерживается .Net Core, но теперь он поддерживается .Net Core 3.1 с поддержкой WinForms. (На самом деле второй говорит о настройках конфигурации времени выполнения, а не о пользовательских настройках)   -  person Matthew Watson    schedule 09.09.2020
comment
Похоже, вы вызвали ошибку Visual Studio, я бы сообщил об этом с помощью встроенного инструмента обратной связи.   -  person Ian Kemp    schedule 09.09.2020
comment
@IanKemp Да, я сделаю это.   -  person Matthew Watson    schedule 09.09.2020
comment
Вы можете добавить пакет управления конфигурацией в свое приложение, чтобы читать существующую конфигурацию, пока вы не перенесете ее в конфигурацию .NET Core. Для этого даже не нужен .NET Core 3.1, пакет .NET Standard 2.0. В прошлый раз, когда я пробовал это при переносе веб-приложения ASP.NET MVC, было на удивление мало проблем, кроме необходимости вручную переименовывать файлы конфигурации. Я отказался от этого из-за тысячи других сокращений бумаги и необходимости просмотра отчетов SSRS. Единственный доступный компонент - WebForms...   -  person Panagiotis Kanavos    schedule 10.09.2020
comment
Если это новый проект, почему бы вам не использовать конфигурацию .NET Core напрямую? Я использовал его в старых проектах .NET для извлечения параметров конфигурации из общих файлов и баз данных вместо app.config. Вместо ограниченных config вариантов, основанных на среде, или хаков с преобразованием, вы можете легко получить отладку, выпуск, производство, разработку и т. д. в любой комбинации, которую вы хотите. Классы конфигурации со строгой типизацией тривиальны. Чтобы сделать то же самое с app.config, вам нужно было скомпилировать класс в отдельной библиотеке и включить его в app.config.   -  person Panagiotis Kanavos    schedule 10.09.2020
comment
@PanagiotisKanavos Это не новый проект - судя по названию, я переношу проекты .Net Framework.   -  person Matthew Watson    schedule 10.09.2020
comment
Не нужно внедрять SomeOtherProject.Settings в классы, чтобы получить доступ к настройкам, достаточно IConfiguration интерфейсов. Нет сломанного кода, если вы рефакторите проекты   -  person Panagiotis Kanavos    schedule 10.09.2020
comment
@PanagiotisKanavos Предполагается, что он поддерживается .Net Core 3.1, поэтому я поднял ошибку. Надеюсь Microsoft это исправит! (Было бы много работы, чтобы изменить все наши проекты, которые используют файл .settings - я изучил его.) Обратите внимание, что настройки действительно работают! Это просто досадная ошибка, от которой я хочу избавиться.   -  person Matthew Watson    schedule 10.09.2020
comment
@MatthewWatson, вероятно, проще перенести конфигурацию на место. Эта область меньше, чем миграция всего приложения. Это также может помочь упростить текущий код.   -  person Panagiotis Kanavos    schedule 10.09.2020
comment
@PanagiotisKanavos Проще, чем вообще не менять код? Думаю, нет. Приложения в настоящее время работают нормально, как я уже сказал, нужно исправить только сообщение об ошибке.   -  person Matthew Watson    schedule 10.09.2020
comment
Я имею в виду весь проект миграции. Даже если вы преодолеете эту ошибку, вы все равно будете использовать устаревшую конфигурацию, которую рано или поздно придется изменить, особенно если вы начнете использовать пакеты, зависящие от Configuration.Abstractions. Баланс неясен и зависит от того, как сейчас используются настройки — многопроектное решение с использованием Settings в каждой папке выиграет гораздо больше от упрощения, предлагаемого Microsoft.Extensions.Configuration.   -  person Panagiotis Kanavos    schedule 10.09.2020
comment
@PanagiotisKanavos Это выходит за рамки текущего этапа нашего процесса переноса, который, вероятно, продлится годами (у нас есть более миллиона строк кода .Net Framework C #, с которыми нужно справиться). Я ищу решение для того, над чем мы сейчас работаем! Я сообщил об ошибке в Microsoft, так что, надеюсь, они ее исправят.   -  person Matthew Watson    schedule 10.09.2020