I'm currently creating a Login form and have this code:
string connectionString = ConfigurationManager.ConnectionStrings["ConnectionString"].ConnectionString;
try
{
using (OdbcConnection connect = new OdbcConnection(connectionString))
{
connect.Open();
OdbcCommand cmd = new OdbcCommand("SELECT username, password FROM receptionist", connect);
OdbcDataReader reader = cmd.ExecuteReader();
if (username_login.Text == username && password_login.Text == password)
{
this.Hide();
MessageBox.Show("Invalid User", "Login Error", MessageBoxButtons.OK, MessageBoxIcon.Error);
this.Close();
}
else
MessageBox.Show("Invalid User", "Login Error", MessageBoxButtons.OK, MessageBoxIcon.Error);
connect.Close();
}
}
catch (OdbcException ex)
{
MessageBox.Show(ex.Message, "error", MessageBoxButtons.OK, MessageBoxIcon.Error);
}
But whenever I try to type in the username and password there is an error called "Configuration system failed to initialize". What kind of problem is this, and how could I solve this?
Make sure that your config file (web.config if web, or app.config if windows) in your project starts as:
<?xml version="1.0"?>
<configuration>
<configSections>
<sectionGroup name="applicationSettings"
type="System.Configuration.ApplicationSettingsGroup, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
<section name="YourProjectName.Properties.Settings"
type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
requirePermission="false" />
</sectionGroup>
</configSections>
</configuration>
Note that inside the configuration element, the first child must be the configSections element.
In the name property on section element, make sure you replace YourProjectName with your actual project's name.
It happened to me that I created a webservice in a class library project, then I copied (overwriting) the config file (in order to bring the endpoints configuration) to my windows app and I started to have the same problem. I had inadvertently removed configSections.
Delete old configuration files from c:\Users\username\AppData\Local\appname and c:\Users\username\AppData\Roaming\appname and then try to restart your application.
Sometimes the Error occurs because a windows create a duplicate in the
C:\Users\App Data\Local\"You App Name"...
Just delete this folder and done. try it.
If you've added your own custom configuration sections to your App.Config, make sure you have defined the section in the <configSections> element. I added the my config XML but forgot to declare the configuration section up top - which caused the exception "Configuration system failed to initialize" for me.
After a long search I realised, this exception has an inner exception that tells you exactly what is wrong with your config file
I had this same problem with an MSTest class: Marlon Grech in his article says "the element has to be defined as the first element in the App.config."
So make sure that is the first element in under the element. I had put AppSettings first.
If you have User scoped settings you may also have a user.config file somewhere in the [Userfolder]\AppData\Local\[ProjectName] folder.
If you later remove the User scoped settings the user.config will not automatically be removed, and it's presence may cause the same error message. Deleting the folder did the trick for me.
I know this has already been answered but I had exactly the same problem in my unit tests. I was tearing my hair out - adding an appSettings section, and then declaring the configuration section as per the answer. Finally found out that I had already declared an appSettings section further up my config file. Both sections pointed to my external settings file "appSettings.config" but the first appSettings element using the attribute file whilst the other used the attribute configSource. I know the question was about the connectionStrings. Sure enough, this happens if the appSettings element is the connectionStrings element being duplicated with different attributes.
Hopefully, this can provide someone else with the solution before they go down the path I did which leads to wasting an hour or two. sigh oh the life of us developers. We waste more hours some days debugging than we spend developing!
I started to get this problem after uninstalling Oracle Client Drivers and it removed my C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\machine.config!
Copying it from another computer resolved the problem.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key="xyz" value="123" />
</appSettings>
</configuration>
Easy solution for .Net Core WinForms / WPF / .Net Standard Class Library projects
step 1: Install System.Configuration.ConfigurationManager by Nuget Manager
step 2: Add a new App.Config file
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key="Bodrum" value="Yalikavak" />
</appSettings>
</configuration>
step3: Get the value
string value = ConfigurationManager.AppSettings.Get("Bodrum");
// value is Yalikavak
If you are calling it from a Class Library then add the App.Config file on your Main Project.
Wow it took me forever to figure out this one. For some reason changing the attribute [assembly: AssemblyCompany("CompanyName")] at AssemblyInfo.cs made this error disappear. I was referencing a project that had a different value for the attribute [assembly: AssemblyCompany("CompanyName")]. I maked sure both projects had the same attribute value and it worked great!
Same problem with me I solved my problem by removing verion="v3.5" from App.config.
Before
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5.2"/>
</startup>
<supportedRuntime version="v3.5" />//Remove this
</configuration>
Solution
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5.2"/>
</startup>
</configuration>
Here is how to use version on
MSDN Support Runtime Element
I solved the problem by using the below code
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<sectionGroup name="applicationSettings"
type="System.Configuration.ApplicationSettingsGroup, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
<section name="YourProjectName.Properties.Settings"
type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
requirePermission="false" />
</sectionGroup>
</configSections>
<appSettings>
<add key="SPUserName" value="TestUser" />
<add key="SPPassword" value="UserPWD" />
</appSettings>
</configuration>
It is worth noting that if you add things like connection strings into the app.config, that if you add items outside of the defined config sections, that it will not immediately complain, but when you try and access it, that you may then get the above errors.
Collapse all major sections and make sure there are no items outside the defined ones. Obvious, when you have actually spotted it.
In my case the only solution was to add the reference to the System.Configuration in my Test project as well.
This is kinda dumb, but for me I fixed it by doing a get latest from source control on my code. I think there was some new configuration element that was added by someone else, and I needed to overwrite my configuration files. OP shows the error I had gotten, which wasn't really pointing me in the right direction.
I too faced the same problem, But accidentally i written the
without writting the ,the previous one should go inside this tags. thus the 'Configuration System Failed to Initialize' error was arising.
Hope it will help
In My case, I have two configsections in the app.config file. After deleting the one hiding in the code lines, the app works fine.
So for someone has the same issue, check if you have duplicate configsections first.
If you are dealing with an Azure WebJob - I had to remove the following after upgrading to the latest 4.6.1.
<compilation debug="true" targetFramework="4.6.1">
<assemblies>
<add assembly="System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
</assemblies>
</compilation>
Hope this helps.
In my case, within my .edmx file I had run the 'Update Model From Database' command. This command added an unnecessary connection string to my app.config file. I deleted that connection string and all was good again.
Try to save the .config file as utf-8 if you have some "special" characters in there. That was the issue in my case of a console application.
As #Flash Gordon mentioned in his comment, you will need to define any custom tag (as a section) in your App.config file, under <configSections>. For example, you're working on a test automation project with SpecFlow & adding <specFlow> tag, then a simplest version of App.config will look like this:
I just had this and it was because I had a <configuration> element nested inside of a <configuration> element.
I restarted Visual studio and even the whole PC.
I cleaned the project, rebuild, and deleted bin file.
Nothing helped until i changed the configuration from x64 to x86.
It worked on x86 but when i changed it back it also worked!
I tried all of the solutions above trying to figure out why one of my unit tests were failing to pick up the configuration from an app.config file that is perfect.
I had 2 references to the same assembly like so:
Removing the (duplicate) reference in yellow fixed it for me.
I hope this works for someone else, it drove me nuts for a while.
If you have a custom section, you need to mention that under configSections right below configurations tag.
Please check your transform files, make sure you remove the unnecessary tags.only the section that are going to vary needs to be there in transform files. dont mention config section in the transform files if not needed. this would also cause the problem.
if you have any syntax error in machine.config, then also this error is expected.
I was also getting
'System.Configuration.ConfigurationErrorsException' in System.Configuration.dll
If you have windows check the slashes / I was working with a project from a guy working in linux, so he had inverted them.
I have recently tried to migrate the NServiceBus libraries to the GAC as they are pretty big and are required in nearly all of my software. I am using the newest .NET 4.0 Build (2.0.0.1219) and have used GACUTIL to copy NServiceBus & NServiceBus.Core into the new GAC and log4net into the old 2.0 GAC. I have managed to get log4net working by wiring in the version and PublicKeyToken but I cannot get the NServiceBus.Core working. Every time I start a piece of software I get the following error:
"Type NServiceBus.Unicast.Transport.CompletionMessage was not registered in the serializer. Check that it appears in the list of configured assemblies/types to scan."
When I copy the DLL NServiceBus.Core to the local folder it works fine.
my config looks like this:
<configSections>
<section name="MsmqTransportConfig" type="NServiceBus.Config.MsmqTransportConfig, NServiceBus.Core, Version=2.0.0.1219, Culture=neutral, PublicKeyToken=9fc386479f8a226c" />
<section name="UnicastBusConfig" type="NServiceBus.Config.UnicastBusConfig, NServiceBus.Core, Version=2.0.0.1219, Culture=neutral, PublicKeyToken=9fc386479f8a226c" />
<section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler,log4net, Version=1.2.10.0, Culture=neutral, PublicKeyToken=1b44e1d426115821" />
<sectionGroup name="common">
<section name="logging" type="Common.Logging.ConfigurationSectionHandler, NServiceBus.Core, Version=2.0.0.1219, Culture=neutral, PublicKeyToken=9fc386479f8a226c"/>
</sectionGroup>
So i'm wondering has anyone else got NServiceBus successfully working with the GAC?
Cheers
It is an issue with NServiceBus stripping strong names. Use the <runtime> element in web.config:
<runtime>
<qualifyAssembly partialName="MessagesDll" fullName="MessagesDll, Version=1.0.0.0, Culture=neutral, PublicKeyToken=4d476a51357cea5c" />
NServiceBus scans the assemblies in a directory (the run directory for an application, the website's compiled directory for a web application) in order to load all the message handlers, and that means it needs to scan itself as well for all the types it needs for dependency injection.
I'm not sure that this model supports assemblies living in the GAC by default, although if you're configuring NServiceBus yourself, you can specify the assemblies to load yourself through the NServiceBus.Configure.With(params Assembly[] assemblies) overload, just make sure to include all the NServiceBus assemblies and Log4Net at the very least.
However, I would contend that GAC-ing the NSB assemblies might not be the best idea. Each endpoint having its own copy of the assembly reinforces the autonomy of the endpoints, and will make it much easier if you ever need to upgrade to a new version of NServiceBus, since you would be able to test each endpoint individually and not just put a new assembly in the GAC, add a binding redirect, and hope everything continues to run fine.
I have an assembly with few versions registered in the GAC. Now, I want one of my clients which uses this assembly (version 1.3) to point to the newest version (1.4) without opening the source and recompiling the client.
I saw an article demonstrating a technique for doing so using the application config file (winform application)
here is the config file content :
<?xml version="1.0" encoding="utf-8" ?>
<configuration xmlns:asm="urn:schemas-microsoft-com:asm.v1">
<runtime>
<asm:assemblyBinding>
<!-- one dependentAssembly per unique assembly name -->
<asm:dependentAssembly>
<asm:assemblyIdentity
name="MyFacade"
publicKeyToken="c9c18e16df1654e0" />
<!-- one bindingRedirect per redirection -->
<asm:bindingRedirect oldVersion="1.3.0.0"
newVersion="1.4.0.0" />
</asm:dependentAssembly>
</asm:assemblyBinding>
</runtime>
</configuration>
As you can see, there is a binding redirect from version 1.3.0.0 to 1.4.0.0 for assembly named MyFacade.
Now, there's only a Minor issue with this approach. It doesn't work :)
I'm sure it's something with my code.
Any suggestions?
Thanks,
Adi Barda
first, this is the best source I've found about this subject. There are some differences, for example, they are not using the asm: namespace, and also, you might want to disable the publisher policy by adding <publisherPolicy apply="no" /> as described in the article.
In a previous project we did, we needed even more control, so we needed to catch the AppDomain.AssemblyResolve Event and route to any assembly we wanted. Here you can find more informations about the concept. You'd have to manipulate your app once, though.