Starting with .net 4.7, empty System.Windows.Forms.ApplicationConfigurationSection added to web.config

[aludin]

I have an asp.net app which can be updated using a dedicated settings page. The corresponding controller writes those settings as key/values under appsettings in the web.config file (to be precise, appsettings uses a referenceSource attribute to reference the file where the appSettings are actually written). This works file with all previous versions of the .net framework.

Starting from .net framework 4.7, the following issue has appeared:

• An empty System.Windows.Forms.ApplicationConfigurationSection is added to web.config when the configuration is saved. From my understanding this section has been added to .net 4.7 and cannot be empty.
• Not sure why System.Windows.Forms.ApplicationConfigurationSection is added to web.config

The code for saving the app configuration is given below:

public static void SetWebConfigValue(string keyValue, string value)
       {
           if (!string.IsNullOrEmpty(keyValue))
           {
               Configuration config = System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration("~");
              
               AppSettingsSection appSettings = config.AppSettings;

               KeyValueConfigurationCollection settings = appSettings.Settings;

               if (KeyExists(settings.AllKeys, keyValue))
               {
                   settings.Remove(keyValue);
               }
               settings.Add(keyValue, value);
               config.Save(ConfigurationSaveMode.Modified, true);
           }
       }

[richlander]

I sent mail to the team ...

[aludin]

@richlander Thanks for this...for info I have also created a SO "issue" and at least one person confirms this problem: https://stackoverflow.com/questions/44764032/why-latest-net-4-7-adds-an-invalid-configsection-to-my-web-config. This problem happened since the latest Windows 10 "creator's update" was pushed on the target machine and I have managed to reproduce it in my own dev environment.

[adreddy507]

Thank you so much aludin for reporting this. Our team has identified the issue and working on a solution that will be available in the next release of .NET framework/Operating System. Meanwhile, you can safely remove the empty <System.Windows.Forms.ApplicationConfigurationSection/> section from web config file and unblock your applications.

[aludin]

@adreddy507 Many thanks for the feedback. Yes I realized that by removing the <System.Windows.Forms.ApplicationConfigurationSection/> section, the problem is solved. This problem was triggered when I was updating the appSettings child elements. As a workaround I have modified the appsettings element to reference an external file using the <appSettings file="path to file"/> syntax. When programmatically updating that external xml file, the issue is not triggered.

[narc0tiq]

I actually got this in an app.config for a desktop application -- at one point during initialization, the application runs System.Net.Dns.GetHostName(), which tries to load the app.config and fails (on a .Net 4.5 machine). I'm not at all sure where along the pipeline a .Net 4.7 machine was involved, but it ended up that the only difference between a working config and non-working one was the extra System.Windows.Forms.ApplicationConfigurationSection, as mentioned in the OP.

A slightly sanitized stack trace is below.

Application : TheDesktopApp.exe
Version du Framework : v4.0.30319
Description : le processus a été arrêté en raison d'une exception non gérée.
Informations sur l'exception : System.Configuration.ConfigurationErrorsException
Pile :
   à System.Configuration.ClientConfigurationSystem.EnsureInit(System.String)
   à System.Configuration.ClientConfigurationSystem.PrepareClientConfigSystem(System.String)
   à System.Configuration.ClientConfigurationSystem.System.Configuration.Internal.IInternalConfigSystem.GetSection(System.String)
   à System.Configuration.ConfigurationManager.GetSection(System.String)
   à System.Configuration.PrivilegedConfigurationManager.GetSection(System.String)
   à System.Net.Configuration.SettingsSectionInternal.get_Section()
   à System.Net.Sockets.Socket.InitializeSockets()
   à System.Net.Dns.GetHostName()
   à Logging.CustomLogger.InitialiseLogging(System.String, System.String)
   à TheDesktopApp.MainWindow..ctor()
   à TheDesktopApp.App.OnStartup(System.Windows.StartupEventArgs)
   à System.Windows.Application.<.ctor>b__1(System.Object)
   à System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate, System.Object, Int32)
   à MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(System.Object, System.Delegate, System.Object, Int32, System.Delegate)
   à System.Windows.Threading.DispatcherOperation.InvokeImpl()
   à System.Windows.Threading.DispatcherOperation.InvokeInSecurityContext(System.Object)
   à System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   à System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   à System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
   à System.Windows.Threading.DispatcherOperation.Invoke()
   à System.Windows.Threading.Dispatcher.ProcessQueue()
   à System.Windows.Threading.Dispatcher.WndProcHook(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef)
   à MS.Win32.HwndWrapper.WndProc(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef)
   à MS.Win32.HwndSubclass.DispatcherCallbackOperation(System.Object)
   à System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate, System.Object, Int32)
   à MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(System.Object, System.Delegate, System.Object, Int32, System.Delegate)
   à System.Windows.Threading.Dispatcher.LegacyInvokeImpl(System.Windows.Threading.DispatcherPriority, System.TimeSpan, System.Delegate, System.Object, Int32)
   à MS.Win32.HwndSubclass.SubclassWndProc(IntPtr, Int32, IntPtr, IntPtr)
   à MS.Win32.UnsafeNativeMethods.DispatchMessage(System.Windows.Interop.MSG ByRef)
   à System.Windows.Threading.Dispatcher.PushFrameImpl(System.Windows.Threading.DispatcherFrame)
   à System.Windows.Threading.Dispatcher.PushFrame(System.Windows.Threading.DispatcherFrame)
   à System.Windows.Threading.Dispatcher.Run()
   à System.Windows.Application.RunDispatcher(System.Object)
   à System.Windows.Application.RunInternal(System.Windows.Window)
   à System.Windows.Application.Run(System.Windows.Window)
   à System.Windows.Application.Run()
   à TheDesktopApp.App.Main()

[richlander]

I just sent mail to the team again.

[adreddy507]

Hi narc0tiq,

Is it possible to send us a sample app here? Also, can you please provide following details?

1. Confirm exact version of .NET framework installed on the machine. you can follow instructions listed here : https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/how-to-determine-which-versions-are-installed#net_b
2. What is the OS running ( OS version)
3. if sample application is not available, what is the targeted framework of the application.

Thanks,

[narc0tiq]

Sample app might take a while, because I'm in the middle of other stuff, but let me get you the other data:

1. HKLM\SOFTWARE\Microsoft\Net Framework Setup\NDP\v4\Full\Release says 460798 decimal, i.e. .NET Framework 4.7 on Windows 10 Creators Update (I haven't had a chance to grab the Fall Creators Update yet)
2. "About your PC" says it is Windows 10 Pro v.1703, build 15063.674
3. All the projects in the (large) solution are targeting the .NET Framework 4.5.1 (for compatibility reasons).

Naturally, the app.config with extra System.Windows.Forms.ApplicationConfigurationSection works just fine on my machine, but then fails when copied to other machines, such as a Windows 7 SP1 Enterprise machine with the release 379893 decimal (.NET Framework 4.5.2) installed. Obviously, a solution is "delete the rogue config section", but it's a pain point that really shouldn't happen, IMO.

In case it's not obvious, the application rewrites its own app.config (using the System.Configuration.ConfigurationManager), and the extra section only appears when running on the machines with netfx-4.7, but if the modified config then arrives on another machine running netfx-4.5, it will not work there, with the first visible pain point being if it does System.Net.Dns.GetHostName() in a constructor for something like a WPF Window.

[adreddy507]

Hi,
We tried to repro this with following code snippet in a sample winforms application but were not successful. We did take a fix earlier in the product cycle and it should be present in the release version you mentioned above. If you are still seeing this issue with latest .NET framework, please share us your sample application to help us identify the problem.

Sample code used to repro:

private void Form1_Load(object sender, EventArgs e)
{
string hostName = System.Net.Dns.GetHostName();
this.textBox1.Text = hostName;
System.Net.IPHostEntry ipEntry = System.Net.Dns.GetHostEntry(hostName);
System.Net.IPAddress[] addr = ipEntry.AddressList;
string IPAddress = addr[0].ToString();
this.textBox2.Text = IPAddress;
}

Thanks

[narc0tiq]

Ok, I've got code: https://github.com/narc0tiq/dotnet-temp/

Reproduction steps are in the readme, but essentially involve:

• running the app on a machine with .NET Framework 4.7 and making it edit app.config,
• copying the app to a machine with a lesser version (4.6.1 in my testing, since that's what I had handy),
• and then running the app on that other machine, which will display the problem immediately.

The projects include <TargetFrameworkVersion>v4.5.2</TargetFrameworkVersion> and the app.configs contain <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5.2"/>, so the ConfigurationManager should be able to tell whether System.Windows.Forms.ApplicationConfigurationSection is permitted or not (it's not).

[adreddy507]

Thank you so much for this narc0tiq. We will be looking at it and update this thread soon.

[kalaskarsanket]

This issue has not got any input for long time and we have changed were issues are tracked. If this is still an issue kindly raise a new issue in the appropriate repo as mentioned in dotnet/1275