3

I've run into an issue while porting some of our .Net Framework projects to .Net Core. After porting, if the project has an "app.config" AND a "Settings.settings" file I get an error every time that I open the project or view the project properties.

After some investigation, I've managed to reproduce the problem without porting - just by creating a .Net Core Windows Forms app and then adding an app.config and a settings.settings as follows:

Using Visual Studio 2019 version 16.7.3 (error also occurs with older versions):

  1. Create a new "Windows Forms App (.Net Core)" .Net Core 3.1 project.
  2. In the IDE, right-click the project in Solution Explorer and select Add | New Item...
  3. Select "Application Configuration File" and click 'Add'.
  4. Go to "Project Properties" and the "Settings" tab.
  5. Click "This project does not contain a default settings file. Click here to create one."
  6. Add a string user setting called "Setting" with a value of "test".
  7. Build application.
  8. Close all the project windows.
  9. Go to "Project Properties" and the "Settings" tab.

At this point I see an error:

An error occurred while reading the app.config file. The file might be corrupted or contain invalid XML.

This error is now displayed every time I open the project or go to the project properties.

How can I prevent this error from occuring, other than by deleting "App.Config"?

Note that despite the error, the settings do work correctly - they can be read and written at runtime. It's just an irritating and slightly worrying error message that I'd like to see gone!

[EDIT] I submitted this to Microsoft as a bug here: https://github.com/dotnet/sdk/issues/13478

Matthew Watson
  • 104,400
  • 10
  • 158
  • 276
  • these might help: https://stackoverflow.com/questions/45034007/using-app-config-in-net-core and https://learn.microsoft.com/en-us/dotnet/core/run-time-config/ – Kixoka Sep 09 '20 at 14:31
  • @Kixoka The first of those is out of date, and the second is not relevant because they assume that Settings.settings isn't supported by .Net Core - but it IS supported now, by .Net Core 3.1 with WinForms support. (Actually the second is talking about runtime config settings rather than user settings) – Matthew Watson Sep 09 '20 at 14:34
  • 2
    Sounds like you triggered a Visual Studio bug, I'd report it using the built-in Feedback tool. – Ian Kemp Sep 09 '20 at 15:15
  • 1
    @IanKemp Yes, I'll do that. – Matthew Watson Sep 09 '20 at 15:17
  • You can add the Configuration management package to your application to read existing config until you migrate it to .NET Core configuration. You don't even need .NET Core 3.1 for this, the package is .NET Standard 2.0. Last time I tried this while migrating an ASP.NET MVC web app there were surprisingly few problems, apart from having to manually rename config files. I abandoned this due to a thousand other paper cuts though, and the need for an SSRS report viewer. The only available component is WebForms ... – Panagiotis Kanavos Sep 10 '20 at 08:01
  • If it's a new project, why don't you use .NET Core configuration directly? I've used it in .NET Old projects to pull config settings from common files and databases instead of `app.config`. Instead of limited `config` options based on environment, or hacks with transformation, you can easily get debug, release, production, development, etc in any combination you want. Strongly typed config classes are trivial. To do the same with `app.config` you had to compile the class in a separate library and include it in `app.config`. – Panagiotis Kanavos Sep 10 '20 at 08:03
  • @PanagiotisKanavos It's not a new project - as per the title, I'm porting .Net Framework projects. – Matthew Watson Sep 10 '20 at 08:07
  • No need to inject `SomeOtherProject.Settings` to classes to get access to settings, just an `IConfiguration` interfaces. No broken code if you refactor projects – Panagiotis Kanavos Sep 10 '20 at 08:07
  • @PanagiotisKanavos It's supposed to be supported by .Net Core 3.1, so I've raised a bug against it. Hopefully Microsoft will fix it! (It would be a lot of work to change all our projects that use .settings file - I've looked into it.) Note that the settings do actually work! It's just that annoying error I want rid of. – Matthew Watson Sep 10 '20 at 08:09
  • @MatthewWatson it's probably easier to migrate the configuration in place. That scope is smaller than migrating the entire application. It may help simplify the current code too. – Panagiotis Kanavos Sep 10 '20 at 08:10
  • @PanagiotisKanavos Easier than not changing the code at all? I think not. The applications currently work fine, like I said it's just the error message that needs fixed. – Matthew Watson Sep 10 '20 at 08:10
  • I'm referring to the entire migration project. Even if you overcome the bug, you'll still be using legacy config that has to be changed sooner or later, especially as you start using packages that depend on Configuration.Abstractions. The balance *isn't clear* and depends on how settings are used now - a multi-project solution using `Settings` on each folder would benefit a lot more from the simplification offered by Microsoft.Extensions.Configuration – Panagiotis Kanavos Sep 10 '20 at 08:14
  • @PanagiotisKanavos That's out-of-scope for the current stage of our porting process, which is likely to last for years (We have well over a million lines of .Net Framework C# code to deal with). I'm looking for a solution for what we're working on now! I've reported the bug to Microsoft, so hopefully they'll fix it. – Matthew Watson Sep 10 '20 at 08:16

0 Answers0