none
appSettings file attribute RRS feed

  • Question

  • I've been linking to an external config file using <appSettings file="blah"> since VS 2003. I just created my first 2010 project, and I get no data from my file, nor any error. This functionality works as expected when I point to 3.5 framework.  Another note, if I copy the other config to the debug directory and reference it by file name it works. When I use the UNC path it doesn't. The UNC path has worked for many of my past projects. Maybe it's a 4.0 security setting somewhere?  I tried trusting the network share where the application is saved, and the share where the config file is saved using caspol.exe, noluck. If I copy the project to my local computer, it runs as expected.
    Tuesday, June 14, 2011 3:47 PM

Answers

  • This is the information I recieved back from Microsoft.  They said the issue would be fixed in the next release, but did not specify a date.

     

    Problem

    =========================

    It fails to link to an extensive configuration file via UNC path in .net framework 4.0.

     

    Troubleshooting & Analysis

    =========================

    1.       We captured a Process Monitor log to see that the application is dropped on the remote server, and the external configuration file is located at the parent’s folder using relative path.

    2.       We wrote a demo code to test it and find the issue really exists.

     

    Result

    =========================

    We involved the production team and they said it was a bug about this issue. In addition, I created a bug on the Connect site. You can trace this issue via the following link.

    https://connect.microsoft.com/VisualStudio/feedback/details/695817/external-appsettings-file-does-not-work-for-the-unc-path

     

    • Marked as answer by Wild_Bill.NET Thursday, December 22, 2011 3:23 PM
    Thursday, December 22, 2011 3:23 PM

All replies

  • I can't seem to find the reference, but I remember reading that in .NET 4, the location of any redirection of configuration content (e.g. appsettings) must be local and at the same directory level (or any path under) as the main configuration file. Which is basically what you already have tested...I don't think you can get around that restriction.

    Also, by default caspol is not used in .NET 4.

    --
    Werner

    Wednesday, June 15, 2011 2:23 PM
  • If my project is local, I can point to a share on the network.  For now I've added a shortcut in my Debug directory which seams like a lame work around.

    Wednesday, June 15, 2011 4:27 PM
  • Yes it does :). Well I stand corrected then, that local restriction must have been something else than application configuration content.

     


    Thursday, June 16, 2011 6:01 AM
  • Hi Bill,

    In the .NET Framework version 4 and later versions, Caspol.exe does not affect CAS policy unless the <legacyCasPolicy> element is set to true.

    More information, you can refer to:

    Caspol.exe

    Sincerely,


    Paul Zhou [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Thursday, June 16, 2011 8:50 AM
  • I added

    <runtime>

    <NetFx40_LegacySecurityPolicy enabled="true" />

    </runtime>

     

     

    to my config file with no luck.


    Thursday, June 16, 2011 4:58 PM
  • I accidently came across the reference I was talking about. It deals with the "configSource" attribute. Perhaps the same restrictions apply for "file" attribute that you use - although not documented. Read this, there are some good suggestions and a few links to follow.

    --
    Werner

    Friday, June 17, 2011 7:26 AM
  • Tried adding file reference in machine.config no luck.  Thanks for the response.  Copying a config to each application in our dev/test/production envrionments would defeat the purpose of using the external configuration file in my case.
    Friday, June 17, 2011 4:31 PM
  • Well, Have you checked that whether you have the privilege to access shared UNC path?

    And could you please tried to copy the file to a local path(not project directory) and use it?

    I suspect that you didn't get the privilege to the UNC path.


    Paul Zhou [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Monday, June 20, 2011 8:44 AM
  • I do have access.  If I point my project to use 3.5 framework everything works as expected, when I point the same project to use 4.0, I get no settings.
    Monday, June 20, 2011 3:16 PM
  • Bump
    Wednesday, June 22, 2011 5:19 PM
  • Applying the <NetFx40_LegacySecurityPolicy> element to a .NET Framework version 4 assembly does not affect security-transparent code; the transparency rules still apply.

    If you specify a target .NET Framework version that is earlier than the .NET Framework 4 in the project settings for your Visual Studio project, CAS policy will be enabled, including any custom CAS policies you specified for that version. However, you will not be able to use new .NET Framework 4 types and members. You can also specify an earlier version of the .NET Framework by using the <supportedRuntime> element in the startup settings schema in your application configuration file.

    Maybe you could try to specify an earlier version of the .NET Framework.

     


    Paul Zhou [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Thursday, June 23, 2011 7:37 AM
  • Unfortunatly that will not work for me, as I am referencing several assemblies compiled in 4.0.
    Thursday, June 23, 2011 3:13 PM
  • Bump
    Tuesday, July 12, 2011 2:24 PM
  • Did you ever get it sorted out? If not then perhaps you can use a symbolic link and load the config file from that. Read about it on this blog.

    --
    Werner


    • Edited by Werner Clausen Monday, September 26, 2011 2:32 PM
    • Marked as answer by Wild_Bill.NET Thursday, December 22, 2011 3:23 PM
    • Unmarked as answer by Wild_Bill.NET Thursday, December 22, 2011 3:23 PM
    Monday, September 26, 2011 2:31 PM
  • This is the information I recieved back from Microsoft.  They said the issue would be fixed in the next release, but did not specify a date.

     

    Problem

    =========================

    It fails to link to an extensive configuration file via UNC path in .net framework 4.0.

     

    Troubleshooting & Analysis

    =========================

    1.       We captured a Process Monitor log to see that the application is dropped on the remote server, and the external configuration file is located at the parent’s folder using relative path.

    2.       We wrote a demo code to test it and find the issue really exists.

     

    Result

    =========================

    We involved the production team and they said it was a bug about this issue. In addition, I created a bug on the Connect site. You can trace this issue via the following link.

    https://connect.microsoft.com/VisualStudio/feedback/details/695817/external-appsettings-file-does-not-work-for-the-unc-path

     

    • Marked as answer by Wild_Bill.NET Thursday, December 22, 2011 3:23 PM
    Thursday, December 22, 2011 3:23 PM
  • Work around is to manually copy the file to the bin/programfiles directory
    Monday, January 30, 2012 10:08 PM
  • I understand that, but in my case it would involve hundreads of console applications, which is why we moved towards the shared config file in the first place.
    Tuesday, April 3, 2012 5:22 PM
  • Wild Bill, we are in the situation that we need to use shared config, what did you end up doing to solve this problem?  I am trying all sorts of things and so far nothing is working just right.  I have the "file" attribute of the appSettings kind of working, but I can't update the config values which is troublesome.
    Thursday, August 30, 2012 9:43 PM