none
The configSource attribute must be a relative physical path?

    Question

  • Hi,

    I get the following error when I try to specify the configSource attribute for my configuration section:

    "The configSource attribute must be a relative physical path."

    Does this mean what I think that it does? Sad That the path must be relative to either the configuration file or the application exe?

    I get this error when I define the configSource attribute to "\\servername\\share\\filename.xml" or "C:\\filename.xml". But if I define it as ".\\filename.xml" it works.

    The problem is that our customer wants part of the configuration on the server, so that they only have to change it in one place. I thought that I could solve it like this, but it seams that it isn't that easy?

    Regards,
    Lani
    Thursday, November 24, 2005 3:02 PM

Answers

  • Unfortunately what you're trying to do is not supported by the Whidbey configuration system. The external file must be in a relative physical path (relative to the original configuration file that points to it). The limitation is because of security considerations, but I agree that we can relax it a little, and allow you to point at UNC shares at least from the root configuration file (machine.config or root web.config).
    Monday, November 28, 2005 7:19 PM

All replies

  • It even get worse that this, I've now got this error:

    "The configSource attribute is invalid.: The configSource '..\\\\..\\\\departmentConfiguration.xml' is invalid. It must refer to a file in the same directory or in a subdirectory as the configuration file.

    Why this limitation? If it is because of security then I think the security aspect has gone too far in .NET, as security is the only reason I can think of? If the user has the right to access a file, why not just let him?

    But maybe there is a better solution to my original problem already built in into .NET or Enterprise Library?

    Thursday, November 24, 2005 3:20 PM
  • Unfortunately what you're trying to do is not supported by the Whidbey configuration system. The external file must be in a relative physical path (relative to the original configuration file that points to it). The limitation is because of security considerations, but I agree that we can relax it a little, and allow you to point at UNC shares at least from the root configuration file (machine.config or root web.config).
    Monday, November 28, 2005 7:19 PM
  • That would be a much appreciated change. And in my case if the app.config (myapp.exe.config) would count as a root configuration file.

    Will it be decided if the change is going to be made? And if it is, when is an update be expected?

    Thank you for getting back to me on this matter as well.

    Regards
    ,
    Lani

    Tuesday, November 29, 2005 4:05 PM
  • I don't have a good answer to that I'm afraid...
    There is planning going on for the next version, but official dates and final decisions are still somewhat far away.
    Tuesday, November 29, 2005 5:57 PM
  • This is a terrible change to config files, I have no idea why this has been put in place.

    We have a system which has 12 web services which all connect to the same database.  In our .NET 1.1 app, we able to have a shared dataConfiguration.config file which contained the database settings.  This meant that when the customer changes their database, they could just chance this file once and be guaranteed that all the web services would connect to the new database.

    This is no longer possible, we will have to instruct the customer to copy the new config file separately into each web service.  The implications of this are massive increased support costs for us and the customer, as if they forget to copy the file into one of the directories it will cause the system to fail without us having any immediate knowledge of it.
    Monday, March 27, 2006 9:39 AM
  • When will this be FIXED ?
    Tuesday, May 02, 2006 2:28 AM
  • To be clear, I am not aware of any regressions that v2.0 has relative to v1.x in that context. As far as I know, configSource never allowed you to point to arbitrary config files, only to relative physical paths. You could still share your database configuration settings by having them in a parent configuration file (such that your web service applications all inherit that configuration).

    I hope it helps.

    Shai

    Tuesday, May 02, 2006 4:45 PM
  • Any solution to let configSource attribute support UNC share? or any alternative solution for us to centralize and share the configuration files?

    I was using EL 2.0 and read Tom's article at http://blogs.msdn.com/tomholl/archive/2006/04/02/entlib2externalconfig.aspx about the configSource usage, but i too facing problem when my path pointing to a server name (UNC path). Please kindly advice.

    thanks

    Wednesday, May 31, 2006 3:45 AM
  • Here's a blog post that may be interesting in this context - it talks about the upcoming IIS 7.0 configuration features (available with Windows Vista and later with Longhorn Server):

    http://spaces.msn.com/shaikariv-ms/blog/cns!1E15C67CC48202AB!114.entry?_c11_blogpart_blogpart=blogview&_c=blogpart#permalink

     

    Wednesday, June 07, 2006 9:28 PM
  •  Shai Kariv - MSFT wrote:

    Here's a blog post that may be interesting in this context - it talks about the upcoming IIS 7.0 configuration features (available with Windows Vista and later with Longhorn Server):

    http://spaces.msn.com/shaikariv-ms/blog/cns!1E15C67CC48202AB!114.entry?_c11_blogpart_blogpart=blogview&_c=blogpart#permalink



    The focus is very much on ASP.NET these days; don't forget about us who still makes WinForm applications.

    Regards,
    Lani
    Wednesday, May 30, 2007 7:14 AM