29

Resolved

FileConfigurationSource not working on web projects

description

<p>I&#39;m using Enterprise Library 5 beta 2. I have moved my loggingConfigurationSection outside of the web.config file. In the web.config file I have added a FileConfigurationSource and the needed section reference. This is working well with app.config files, however on web projects trying to get an instance of LogWriter through the Enterprise Library container throws a FileNotFoundException saying that the file where the FileConfigurationSource points to cannot be found.</p> <p>&nbsp;</p> <p>I&#180;m using relative paths in the configuration, so Enterprise Library should devise that and resolve the file starting from my web app root folder. This same configuration is working in other types of projects.</p> <p>&nbsp;</p> <p>I have revised the source code for FileConfigurationSource and founded that it checks File.Exists before resolving the relative path. Obviously this is not going to work on web apps, because Environment.CurrentDirectory is set to IIS startup directory, not the web app base directory. However it could do if it combines relative paths with AppDomain.Current.BaseDirectory before checking it the file exists, and also it will work with other types of projects. This is the code in its current form:</p> <p>&nbsp;</p> <p>private static string GetRootedCurrentConfigurationFile(string configurationFile)</p> <p>{</p> <p> if (string.IsNullOrEmpty(configurationFile))</p> <p> {</p> <p> throw new ArgumentException(Resources.ExceptionStringNullOrEmpty, &quot;configurationFile&quot;);</p> <p> }</p> <p> if (!File.Exists(configurationFile))</p> <p> {</p> <p> throw new FileNotFoundException(string.Format(CultureInfo.CurrentCulture, Resources.ExceptionConfigurationLoadFileNotFound, new object[] { configurationFile }));</p> <p> }</p> <p> if (!Path.IsPathRooted(configurationFile))</p> <p> {</p> <p> return Path.Combine(AppDomain.CurrentDomain.BaseDirectory, configurationFile);</p> <p> }</p> <p> return configurationFile;</p> <p>}</p>

comments

WeiZhou wrote Apr 22, 2010 at 8:59 AM

I met same problem after upgraded to 5.0. But Microsoft thinks it is low level issue, although is might impact half of web site using EntLib! Faint!

danipham wrote Apr 26, 2010 at 9:55 PM 

    private static string GetRootedCurrentConfigurationFile(string configurationFile)
    {
        if (string.IsNullOrEmpty(configurationFile))
            throw new ArgumentException(Resources.ExceptionStringNullOrEmpty, "configurationFile");

        string path = Path.IsPathRooted(configurationFile)
                ? configurationFile
                : Path.Combine(AppDomain.CurrentDomain.BaseDirectory, configurationFile);
        if (!File.Exists(path))
        {
            throw new FileNotFoundException(
                string.Format(
                    CultureInfo.CurrentCulture,
                    Resources.ExceptionConfigurationLoadFileNotFound,
                    path));
        }
        return path;
    }
This could be a correction.

Simple bug, but prevent migration from EntLib version < 5.0, which concern all users in IIS with relative path.

iceclow wrote Apr 27, 2010 at 12:10 PM

What I want with this issue is to see if someone at p&p gives us a clue wheter this will make into some minor release of 5.0, now that enterprise library hitted RTM.

iceclow wrote Apr 27, 2010 at 12:10 PM

What I want with this issue is to see if someone at p&p gives us a clue wheter this will make into some minor release of 5.0, now that enterprise library hitted RTM.

iceclow wrote Apr 27, 2010 at 12:12 PM

What I wante with this issue, is to see if someone at p&p team can gives us info of whether this will make into next bug fix release, now that enterprise library got to RTM. This is showstopper if you want to use IIS and Enterprise Library.

iceclow wrote Apr 27, 2010 at 12:14 PM

Sorry I hitted the Add Comment button too many times, where is the edit button for comments?

bgungor wrote May 6, 2010 at 6:32 PM

iceclow - I just ran into this issue, didn't find your post during a search, and submitted the same issue. I suggest modifying the code in FileConfigurationSource.cs as danipham has done, and work off of your own source until the next release. You can't wait for the P&P team. They don't release fast enough. BTW, this issue isn't just for webs, but any time you want to use an outside configuration file (we are using it for a separated validation configuration file).

jwcarroll wrote Jun 2, 2010 at 2:14 PM

This same sort of problem exists for windows services as well. Relative paths will resolve to the System32 directory if you are running under the SYSTEM account. Since I didn't want to create a custom build just for this one problem, I went with a small workaround.

The trick is to set the Application.CurrentDirectory to your executing assembly location just long enough to initialize EntLib. If you wrapping your calls to EntLib behind interface boundaries (and you should be!) then this code will work.
    private void Initialize()
    {
        var originalLoc = Environment.CurrentDirectory;
        Environment.CurrentDirectory = new FileInfo(Assembly.GetExecutingAssembly().Location).Directory.FullName;

        Logger.Write("Initailzing Enterprise Library Logging");

        Environment.CurrentDirectory = originalLoc;

        Initialized = true;
    }
For me I put this code into my EntLibLogger class and simply tested for Initialized before doing any logging. It changes the directory just long enough for EntLib to resolve the file location and then changes it back. Something similar could probably be placed in Application_Start in the Global.asax for web applications.

It is worth noting that this is a hack, and requires white-box knowledge of how the configuration file is being referenced, but it will save you from having to keep up with a custom build of EntLib just for this silly little problem.

I hope they fix this and put out a official release with the patch soon.

VitZmk wrote Jul 8, 2010 at 3:02 PM

workaround:
code:
[Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ConfigurationElementType(typeof(FileConfigurationSourceElement))]
class FileConfigurationSource : Microsoft.Practices.EnterpriseLibrary.Common.Configuration.FileConfigurationSource
{

    public FileConfigurationSource(string configurationFilepath)
        : base(configurationFilepath)
    {
    }
}
class FileConfigurationSourceElement : Microsoft.Practices.EnterpriseLibrary.Common.Configuration.FileConfigurationSourceElement
{
    public override Microsoft.Practices.EnterpriseLibrary.Common.Configuration.IConfigurationSource CreateSource()
    {
        string configurationFilepath = System.IO.Path.Combine(AppDomain.CurrentDomain.BaseDirectory, this.FilePath);
        return new FileConfigurationSource(configurationFilepath);
    }
}
config:

henrykf wrote Jul 27, 2010 at 2:34 PM

I have the same problem on "outsourcing" the custom config settings into an other config file.
I can't understand, why it has been set to "low" level. It's crazy...

Captain_Crash wrote Aug 11, 2010 at 1:30 PM

When will entlib developers fix this bug? As I see there is a solution for this bug in the comments. What anything else should folks do? :)

ctavares wrote Aug 18, 2010 at 4:04 AM

Configuration sources are a plug point. Until we ship a new version (which will probably be a while) best best is to copy the code into a new configuration source class in your own project and reference that. No need to recompile Entlib itself, and no need to worry about tracking patches.

Captain_Crash wrote Aug 28, 2010 at 9:31 AM

Thanks for your fast reply and for the reassuring answer. I believe in your expertness and I didn't want to look down on anybody. I'll using the corrected implementation in my code until your patch is not available. :) Keep it up!

timbc wrote Oct 15, 2010 at 3:25 PM

not agree with impact level

tdracz wrote Nov 29, 2010 at 9:02 PM

I noticed on several occasions that Microsoft refuses fixing bugs excusing it with lack of time or diminishing their importance. Just one more example. Really not professional.

TorstenR wrote Feb 4, 2011 at 4:06 PM

When will this get fixed? It is really a pain to maintain the same EntLib entries for X app.config files without an external Entlib.config... (any other workaround?)

TorstenR wrote Feb 21, 2011 at 7:04 AM

It also impact DOT.NET applications running as windows service: I cannot use external entlib.config there, I MUST embedd all the entlib config stuff into the main .exe.config, what a hassle...!!!

TorstenR wrote Feb 21, 2011 at 7:07 AM

This issue has the most votes: can someone please adjust the issue's work item details so it will be assigned to someone and we receive a fix? We do really need this!

gmelnik wrote Feb 22, 2011 at 6:24 PM

TorstenR, yes, this is on the backlog for the next version of EntLib. In the meantime, please use the workaround posted in the comments below.

tdracz wrote Feb 26, 2011 at 6:54 PM

So we will have it fixed after a year or two counting from the original release which may bring us other annoying bugs and you will be fixing them another year or two. A product with such a bugs fixing policy - even as good as this one - doesn't seem to me to be suitable for use in professional software.

gmelnik wrote May 10, 2011 at 2:55 AM

Fixed in Enterprise Library 5.0 Optional Update 1.

jcollum wrote Jun 3, 2011 at 9:42 PM

VitZmk's workaround worked well for me. Just add a cs file to your project with that code in it and you're set. After you update the web.config.

Sign in to add a comment or to set email notifications