locked
"Configuration system failed to initialize" error RRS feed

  • Question

  • So I've been getting this error when I try to run a build of my program.  The inner exception is that the configuration file does not have a root <configuration> tag.  When I wrote my application, I used the application setting class as described here.  Now the tricky part is that when I run the application inside of the IDE, I don't get an error about configuration and it loads my config file just fine.  It's only outside of the IDE when I run the built executable that there's an issue with the configuration.  Can anyone shed some light on the issue?

    Here's the application .config:

    <?xml version="1.0" encoding="utf-8"?>  
    <ApplicationSettings xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">  
      <JustRename>true</JustRename> 
      <UseRenamedDirectory>false</UseRenamedDirectory> 
      <DefaultRenamedDirectory>Z:\TestFile\_RENAMED_</DefaultRenamedDirectory> 
      <DefaultOutputString%file%</DefaultOutputString> 
      <TextReplacements> 
        <Replacement search="REGEX:[(].+[)]" replace="" description="Removes parentheses and all text between them." /> 
      </TextReplacements> 
    </ApplicationSettings> 
    Tuesday, July 29, 2008 3:15 PM

Answers

  • It doesn't look like this file is a configuration file at all.  Try this link to get started looking at the configuration file xml schema.
    David Morton - Consultant - Catapult Systems - Houston
    • Marked as answer by jack 321 Friday, August 1, 2008 5:34 AM
    Tuesday, July 29, 2008 3:29 PM
  • The configuration subsystem (of which application settings bounces off of) will generate this error anytime it tries to load a config file that is in any way corrupt (not a valid XML file) or if a section is defined in the config file that does not have a matching section handler.  I reported the uselessness of this error message back when v2.0 was in beta and it was too late to fix.  I suspect you have a section in your config file that does not have a handler assigned to it.  If you created your own custom sections then that would be it. 

    If you haven't created your own sections then I would lean toward invalid XML.  Perhaps an attribute that is missing quotes or something.  It is also possible that an attribute has an invalid value.  I can't remember if you get this error in that case or not.  The config subsystem is pretty picky about things.

    As David mentioned the config file you posted is not valid for the config subsystem.  Therefore you would get this error if you tried to load it.  The .NET config subsystem expects a root of <configuration>.  Everything will reside under this root element.  Here is how your config file should look:

    <?xml version="1.0" encoding="utf-8" ?> 
    <configuration> 
        <configSections> 
            <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" > 
                <section name="WindowsFormsApplication1.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" /> 
            </sectionGroup> 
        </configSections> 
        <applicationSettings> 
            <WindowsFormsApplication1.Properties.Settings> 
                <setting name="Setting" serializeAs="String">  
                    <value>Value1</value> 
                </setting> 
            </WindowsFormsApplication1.Properties.Settings> 
        </applicationSettings> 
    </configuration> 

    Now the config you posted doesn't look like one that would have been generated by the application settings wizard.  If this is your own custom handler then the layout would be similar except you would be using your own section handler instead.  Of course if you don't care about using the config subsystem at all then you can skip all this and just use the standard XML classes to read/write your file.

    Moving on to why it works inside the IDE and not outside.  In your project file you should have an app.config file where this stuff resides.  When you debug your code inside the IDE app.config gets renamed to <app>.exe.config and copied to the output directory.  Assuming app.config is valid then your app should run just fine.  When you run your app outside of VS then it will use whatever <app>.exe.config file is in the run directory.  If this file were modified (say by your app) then it is possible it is getting corrupted.  When you run inside the IDE you would start with a fresh, valid config but outside you would be using whatever config was generated last.  It's just a hunch on my part here as to what is going on.

    Michael Taylor - 7/30/08
    http://p3net.mvps.org
    • Marked as answer by jack 321 Friday, August 1, 2008 5:34 AM
    Wednesday, July 30, 2008 2:46 PM

All replies

  • It doesn't look like this file is a configuration file at all.  Try this link to get started looking at the configuration file xml schema.
    David Morton - Consultant - Catapult Systems - Houston
    • Marked as answer by jack 321 Friday, August 1, 2008 5:34 AM
    Tuesday, July 29, 2008 3:29 PM
  • Hey, awesome, I totally appreciate a suggestion that's entirely irrelevant to the question I asked.  Whether or not it can be validated by a particular schema doesn't explain why it works fine when run in the Visual Studio IDE and not fine outside of it.
    Wednesday, July 30, 2008 12:18 AM
  • Well, it certainly explains why it doesn't work outside of the IDE.  Isn't that a bit more relevant to your problem than why it might work inside the IDE?  You haven't given us any information that would help us explain the latter.  Create a valid config file, preferably with the IDE's Settings designer.  If it still doesn't work, feel free to post back.
    Hans Passant.
    Wednesday, July 30, 2008 3:50 AM
  • No, it really isn't relevant.  Telling me that my XML doesn't follow a specified schema for configuration files doesn't tell me anything about why my program works inside of the IDE.  I don't use anything in the Configuration namespace explicitly, so it doesn't make a whole lot of sense that it'd suddenly become an integral part of my program outside of the IDE.  Telling me, "Rewrite your application settings using a different method" doesn't explain why there's a problem with what I have currently or why it only works in the IDE when testing.  Seriously, why would I want to hear, "This works, do it this very different way instead" when my question isn't about solving a problem, but understanding the difference in the environments that's causing the underlying issue?  In other words, I don't care if there are a million other, better ways to do what I want to do--that's not what I asked.  I want to know why there's a discrepancy between what the IDE gives me and what compilation gives me.

    And I'm not sure how much more information I could possibly give than an MSDN article that is almost verbatim what's in my application at present.

    Wednesday, July 30, 2008 5:30 AM
  • Can you post the code you use to read this configuration file?

    It sounds like what happens here may be causing this issue

    Thanks
    Wednesday, July 30, 2008 12:11 PM
  • Frankenberry said:

    Hey, awesome, I totally appreciate a suggestion that's entirely irrelevant to the question I asked.  Whether or not it can be validated by a particular schema doesn't explain why it works fine when run in the Visual Studio IDE and not fine outside of it.


    Check this link:

    http://www.distribucon.com/blog/ConfigurationSystemFailedToInitialize.aspx

    I don't know why the error is occurring in one place but not another, but I do know why it's happening anywhere at all.

    If you'd like to find why the error works in one place but not another when you refuse to go with the best practice on the topic, I think you're on your own. 

    If, on the other hand, you'd like to meet your deadlines and accomplish your goal of having a program that works successfully outside the IDE, I would recommend going with the .NET standard for configuration files and using the System.Configuration namespace to access the settings you're trying to do.

    It seems very common that people come into this forum trying to rewrite the (already excellent) .NET Framework, and then they come here and complain that nothing seems to work properly and they want to know why.  If I'm giving advice, I'm trying to do my best to help the original poster with methods that will help them avoid the error altogether.  Whether the error happens in one place or another and doesn't happen somewhere else doesn't interest me as much as preventing the error completely.

    Save yourself the trouble and go with the best practices.  They work.  I've used them.  That's why they're called "Best Practices".

    Oh, and if you're still with me, change the name of the file you're calling the app.config.  It's not an app.config.  Then load the file using the new filename.  That should solve your issue.
    David Morton - Consultant - Catapult Systems - Houston
    Wednesday, July 30, 2008 2:21 PM
  • The configuration subsystem (of which application settings bounces off of) will generate this error anytime it tries to load a config file that is in any way corrupt (not a valid XML file) or if a section is defined in the config file that does not have a matching section handler.  I reported the uselessness of this error message back when v2.0 was in beta and it was too late to fix.  I suspect you have a section in your config file that does not have a handler assigned to it.  If you created your own custom sections then that would be it. 

    If you haven't created your own sections then I would lean toward invalid XML.  Perhaps an attribute that is missing quotes or something.  It is also possible that an attribute has an invalid value.  I can't remember if you get this error in that case or not.  The config subsystem is pretty picky about things.

    As David mentioned the config file you posted is not valid for the config subsystem.  Therefore you would get this error if you tried to load it.  The .NET config subsystem expects a root of <configuration>.  Everything will reside under this root element.  Here is how your config file should look:

    <?xml version="1.0" encoding="utf-8" ?> 
    <configuration> 
        <configSections> 
            <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" > 
                <section name="WindowsFormsApplication1.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" /> 
            </sectionGroup> 
        </configSections> 
        <applicationSettings> 
            <WindowsFormsApplication1.Properties.Settings> 
                <setting name="Setting" serializeAs="String">  
                    <value>Value1</value> 
                </setting> 
            </WindowsFormsApplication1.Properties.Settings> 
        </applicationSettings> 
    </configuration> 

    Now the config you posted doesn't look like one that would have been generated by the application settings wizard.  If this is your own custom handler then the layout would be similar except you would be using your own section handler instead.  Of course if you don't care about using the config subsystem at all then you can skip all this and just use the standard XML classes to read/write your file.

    Moving on to why it works inside the IDE and not outside.  In your project file you should have an app.config file where this stuff resides.  When you debug your code inside the IDE app.config gets renamed to <app>.exe.config and copied to the output directory.  Assuming app.config is valid then your app should run just fine.  When you run your app outside of VS then it will use whatever <app>.exe.config file is in the run directory.  If this file were modified (say by your app) then it is possible it is getting corrupted.  When you run inside the IDE you would start with a fresh, valid config but outside you would be using whatever config was generated last.  It's just a hunch on my part here as to what is going on.

    Michael Taylor - 7/30/08
    http://p3net.mvps.org
    • Marked as answer by jack 321 Friday, August 1, 2008 5:34 AM
    Wednesday, July 30, 2008 2:46 PM
  • That was actually pretty close to what was happening.  So yes, I created my own settings file using that MSDN page referenced in the first post.  Because my application never referenced the configuration subsystem or made any use of it (because I was using the custom class), it didn't make much sense to me that it would try to load the file through the configuration system.  What you said about the IDE kind of makes sense, except that no app.config ever gets generated because as I've said, I don't use the configuration subsystem.  However (and this isn't verified), I'm guessing that when compiled, the executable was looking on its own for a configuration file (in this case, it was <app>.config).  Inside of the IDE, it was either doing what you said and making <app>.exe.config (which I never saw spring into existence) or it was noticing that I don't use the configuration subsystem and didn't try to load any config file.  So to remedy the problem in this case, I changed the extension of my custom configuration file to something other than .config (such as .conf).  Similarly, had I not named the config file <app>.config and named it settings.config, it would have worked just fine (and it does).

    Moral of the story: If using a custom configuration file, naming it <app>.config will cause that error even if your application isn't using the automated configuration subsystem stuff.  (And I just noticed that this was exactly what David Morton said in his post.)

    And while I understand that many people are solely interested in developing code that works, I prefer to understand why code I've written doesn't work so that if I come across similar problems in the future, I have some idea of what to do instead of running back to a forum for the "right way" to do something.  While I'm not thrilled about the prospect of rewriting my configuration to use the System.Configuration namespace (particularly because I serialize a custom class in it and that means learning how to use it within the existing configuration framework), I probably will take it upon myself to learn it so that these issues don't occur in the future.  For the record, it's not my intent to rewrite the .NET framework.  When I searched for "C# save application settings" in Google, the first result was the MSDN page (somewhat old) that suggested I use the method I'm currently using.  It was there, it worked, and it does exactly what I need...  Except apparently being a legitimate form of configuration file.

    • Edited by Frankenberry Saturday, August 2, 2008 4:08 PM Added information.
    Saturday, August 2, 2008 3:42 PM
  • All,
        I am having the exact same problem, word for word, what Frankenberry has. I too followed Microsoft's suggestion for making a "custom" xml config file and a custom class reading in the file using the XmlSerializer class. I had originally compiled the app in .Net 1.0. I have upgraded this app several times to .net 1.1, then 2.0. My problems started when I upgraded the project to VS 2008. The app still targets the 2.0 framework. I had the same issue that debugging the app in the IDE did not throw an error in either debug or release mode. It happened only on the deployed client's PCs. I banged my head against the wall for several hours, trying to add a <configSections> tag and a <configuration> tag. I looked for any reference to System.Configuration in my code and found nothing. Nothing worked until I saw this posting. I renamed the <app>.config file to settings.config and pointed my custom class to load the new name and it now works. 
        I understand the idea of using "Best Practices", but sometimes, old apps don't need all their innerworkings uprooted when small additions or upgrades occur. My hope is to eventually replace the app with other technology as our business needs allow but for now I will read the "Best Practices" and use them in the future.
        The question still remains why this issue occured when I upgraded the solution from VS 2005 using .net 2.0 to VS 2008 using .net 2.0. The version numbers of the dlls show the same number. I am having a similar issue with deploying a .net 2.0 app on a server with a new upgrade from Sql Server 2005 to 2008. I've read several article/post detailing that the .net 2.0 dlls are not the same once .net 3.5 is installed. There are some core innerworkings of the the dlls that changed even though the rev numbers didn't. I have an IIS server running on the same SQL Server (I know, "Best Practices", but it's behind a firewall on an intranet and there were authentication issues about multiple hops) so I cannot upgrade SQL to 2008 until I rebuild my asp.net apps to .net 3.5 for fear of this .net 2.0 dll issue will occur. I didn't seem to have these issues when upgrading from 1.1 to 2.0.

    Thanks for the help.
    Dion

    Monday, February 23, 2009 11:04 PM
  •  If your error is the same as the OP then it can occur at any point when the config subsystem is invoked.  When this occurs can vary by a great number of things.  At the very least any tracing or debug statements can cause the config subsystem to attempt to load the app config.  Additionally any attempt to do anything with the generic ADO.NET classes will likely cause the config subsystem to load.  Expanding from there would be security, localization and any potential runtime configuration checks that may occur. 

    The takeaway is that you should not assume your app config won't be loaded until you explicitly reference it.  It was perhaps just chance that your code running under VS2005 didn't hit on anything that would load the config file.  .NET is moving more and more toward declaration, configurable apps so it is highly likely that even a SP could have altered the behavior enough to trigger the invocation. 

    Unfortunately there is no workaround other than to not use app.config for your file names in VS and to not use app.ext.config (the actual config file) at runtime.

    Michael Taylor - 2/23/09
    http://p3net.mvps.org
    Tuesday, February 24, 2009 3:45 AM
  • Hi All

    I faced the same issue. In my case I did not want to have an app.config but just a couple of xml tags for runtime decisions. Details are

    1-    This xml is not in suggested schema.
    2-    This xml is named in format <projectExeName>.config
    3-    I manually access this file to read XML from it.

    My Problems:

    1-    This project is running fine on clients and I inherited some additional support changes to perform over it.
    2-    What I face is that when I run this application from IDE in debug mode only, it executes fine. But if I execute it without debugging from my IDE or I execute it without IDE, this would throw the above error.

    My Questions:

    1-    Why is it executed in specific mode.
    2-    As a sense of ownership how could I justify its relevently perfect execution at clients.


    Omair


    9221
    Thursday, October 15, 2009 1:46 PM
  • If you call your XML file <myapp>.exe.config then the config subsystem is going to try and use it.  If you want a custom XML file then you have to name it something else.  Note that app.config is special cased in VS such that it gets automatically copied to the output directory and renamed to <myapp>.exe.config during a build (actually when you debug I believe).  Therefore you can't use either name.  Just call your XML file something like <myapp>.xml or something and then you can parse it as a normal XML file without the config subsystem getting in the way.

    BTW you shouldn't post questions to existing, closed topics.  Create a new topic instead.  Most of the time threads that are closed/answered aren't monitored anymore by the original folks.

    Michael Taylor - 10/15/09
    http://p3net.mvps.org
    • Edited by CoolDadTx Thursday, October 15, 2009 1:54 PM BTW
    Thursday, October 15, 2009 1:53 PM
  • Many thanks TaylorMichaelL for sponteneous reply. I will definitely abide by your advice on closed topics. But just want to ask one last question.

    As you said app.config is copied to the output directory and renamed as <myapp>.exe.config but in my case the name of Xml file is <myapp>.config, instead of <myapp>.exe.config. I am getting the same error in both cases. Please confirm that <myapp>.config name could not be used either? i.e. I cant use both, ChangePush.exe.config and ChangePush.config names.

    Omair
    9221
    Friday, October 16, 2009 6:46 AM
  • Your question has caused me to look into this further and I believe I know understand what is going on for the entire thread. 

    The configuration subsystem tries to load <app>.exe.config when it loads (which can be at any time).  If it doesn't find such a file then it fails back to <app>.config (sort of like how it looks for assemblies).  It probably also does some directory searching but I can't confirm right now.  In your case I suspect you have a <app>.config but no <app>.exe.config.  Hence the subsystem fails.  If you were to add a application configuration to your project then I suspect it'll start working again.  Although it might be easier to just rename your config file.

    Now where things start to get interesting and where the original posting was probably leading.  By default when you run your app inside VS you run it under the hosting process (vshost).  vshost was added to speed up debugger startup time and to allow for some other features.  Nevertheless when you build your app.config gets copied to the output as <app>.exe.config.  However when you start the debugger your application isn't what actually starts but rather the host process.  This would normally cause a problem since your configuration would be lost so VS also copies your app.config to vshost.exe.config.  If you don't have an app.config then nothing happens.

    Continuing on when vshost.exe runs and the subsystem needs the config it is going to load vshost.exe.config (if one is available).  If not then it looks for vshost.config.  In your specific case your <app>.config is not properly named so it might end up in the output directory but VS won't copy it to vshost.exe.config.  Furthermore the host process won't try to load your config since it doesn't match the app name.  So I would expect that you don't get any errors while running inside the debugger but when you run outside the debugger the subsystem fails (because you aren't using the hosting process anymore).  You can actually get the problem to occur inside the debugger by disabling the host process (Project Properties -> Debug).  You will then see the same behavior inside and outside the debugger.

    Michael Taylor - 10/16/09
    http:/p3net.mvps.org

    • Proposed as answer by Omair Imran Monday, October 19, 2009 4:58 AM
    Friday, October 16, 2009 1:43 PM
  • Well, I am getting this error on a number of apps lately, so could each one of them suddenly have an invalid configuration file?  I have one which has not changed in 3 years and now I get this error, so how can I fix the system maybe net framework, so things continue to work?

    Thanks.


    Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici covici@ccs.covici.com

    Saturday, July 4, 2015 6:02 AM