2

In an ASP.NET MVC 3 web application I have the problem that settings from the web.config file are completely ignored and the default values are applied. The relevant parts of the file are as follows:

...
<configuration>
    <configSections>
        <section name="MyProject.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=..." requirePermission="false" />
...
<applicationSettings>
    <MyProject.Properties.Settings>
        <setting name="MySetting" serializeAs="String">
            <value>MyValue</setting>
        </setting>
    ...

I made sure that the project name is correct and I also verified that the webserver user has access to the file (using ProcessMonitor to monitor the access).

I also checked this post, but didn't get any further. Are there any other constellations where the web.config settings might be ignored? I never had any problems with the approach shown above (i.e. reference one or more config sections), but today we spent a couple of hours trying to solve this problem and we can't see where we are wrong here.

Update 1

Following @jbl's comment I tried to access the settings as follows:

((ClientSettingsSection)ConfigurationManager.GetSection( "applicationSettings/MyProject.Properties.Settings" )).Settings.Get("MySetting")

Unfortunately, in a local test this (also) worked as expected, but on the server - again - the default values were used and the ones under applicationSettings in the web.config were ignored.

Update 2

Deleting the web application from IIS and creating a new one also didn't work.

Community
  • 1
  • 1
Gorgsenegger
  • 7,356
  • 4
  • 51
  • 89
  • This seems to be the same problem http://forums.asp.net/t/1681296.aspx I'm afraid there is no trivial answer... – jbl Sep 30 '13 at 15:34
  • @jbl The thread you linked to seems to discuss multiple web.config files in different folders. What I see is that there the settings from my single web.config are not applied (as if the file could not be found) and the default values (as specified within the DLL) are used. – Gorgsenegger Oct 01 '13 at 06:55
  • ok, the message on `May 19, 2011 05:22 AM` seemed to stress a difference between accessing the config file and accessing the auto generated class. I was wondering if you were encountering the same issue. – jbl Oct 01 '13 at 13:25
  • @jbl alright, I read through the post again and tried to see whether this would work, unfortunately the result is the same (see updated original question). – Gorgsenegger Oct 02 '13 at 12:53

4 Answers4

1

The answer in my case was a simple as I am embarrassed now, I just feel pleased that it wasn't me alone who overlooked what was wrong:

  • There were a couple of similar entries for WCF webservice endpoints
  • The version of the web.config I used on the server was not the most recent one
  • Four entries were in the web.config being used, five in the latest one
  • I only had problems with the missing entry for the latest entry which unfortunately in my case was used first in code
  • Due to the default setting compiled into the binaries I did get a value, just not the one I expected

As soon as I updated the file with the missing setting all worked fine, so sorry for all the confusion (at least it cost me 50 points...).

Gorgsenegger
  • 7,356
  • 4
  • 51
  • 89
1

In my case I had renamed my project so it didn't find the assembly file anymore using the default stored inside. For example the web.config says 

<section name="MyProject.Properties.Settings"...

but my assembly is now: Company.MyNewProject so you have to change it in the config file aswell, something like

<section name="Company.MyNewProject.Properties.Settings"
fradique
  • 154
  • 1
  • 8
0

Could you try:

ConfigurationManager.OpenExeConfiguration("C:\inetpub\wwwroot\[drill down to Web.config path on server]").GetSection(etc);

I know I've had problems before where I thought I was reading from my Web.config, but I was actually reading from MyDll.dll.config or MyExe.exe.config or something else unintentional.

If that line still produces unexpected results, I could only suggest stepping through your code (attach Visual Studio debugger to your web application) and seeing that the line is indeed hit as you think it is.

pineconesundae
  • 332
  • 1
  • 13
  • I tried to get this to work, but unfortunately I cannot access the *applicationSettings* (not *appSettings*) section (it's always null). Looping over all sections I seem to get some kind of default values instead. If you've got a working example I'd be happy to try that, searching for one on the internet didn't return any results. – Gorgsenegger Oct 09 '13 at 09:00
  • Is there a reason why you are using applicationSettings instead of appSettings? Just to continue testing, try doing this - http://msdn.microsoft.com/en-us/library/610xe886.ASPX. Add that `` tag in your Web.config, add a key in it with some test value, then use the code snippet in the linked page to try to read the test setting. The important part is how the setting is read - `rootWebConfig1.AppSettings.Settings["customsetting1"]`. You can also try loading the Web.config as I noted in my original answer just to be absolutely sure you are using the correct Web.config. – pineconesundae Oct 09 '13 at 14:01
0

You might have covered these ideas in the updates but want to clarify.

The following is what comes to mind:

  1. There are multiple web.config files that are dispersed throughout your site folders. Make sure that there are no other web.config files that are overriding the one you are looking at. These could be in other folders in application or you have transform config files
  2. When you deploy to the server you are not overriding preexisting files so there are web.config files already on the server somewhere. How are you deploying?

  3. There is a global web.config file that is taking precedence. Use the remove tag to remove unwanted settings: http://msdn.microsoft.com/en-us/library/aa309404(v=vs.71).aspx

       <configSections>
       <remove name="CommerceServer/application"/>

Along the same vein try the clear tag as well. http://msdn.microsoft.com/en-us/library/aa903345(v=vs.71).aspx

<configuration>
     <configSections>
         <clear/>
Rafi
  • 2,433
  • 1
  • 25
  • 33
  • 1 - The web application's web.config is at the root, and I also checked that there aren't any other web.configs on the system 2 - The files are definitely updated with the latest versions, I also can edit them directly on the server. Deployment is via copy & paste (it's on a test server) 3 - As said above, there are no other web.config files possibly taking precedence on the system For the last suggestion - the element can only be used for *"web.config files that are not at the application directory level"*. – Gorgsenegger Oct 09 '13 at 08:48