Mar 12, 2010 at 4:49 AM
Edited Mar 12, 2010 at 5:30 AM
I tried the steps you have provided. First thing, Is it really a Web Site type project or a ASP.NET Web Application project? I tried doing a Web Site type project, say New -> Web Site ... But in the 4th step its not giving me an option to add as link.
Also, in a web site type project, there is no bin folder unless you add it explicitly. Then I tried doing it using a ASP.NET Web Application, everything went fine. The logger doesn't fail. I can send you that solution so you could check if i missed something.
Global Technology and Solutions
I apologize, you are correct I meant Web Application Project. I re-read my post and I've been ambiguous as well. Also, the config file needs to be in a project of its own, and that project should be referenced from the Web Application project. The config
link is not necessary. The build process will copy this as a content item alongside the rest of the assemblies, thus arriving in the bin/ folder of your web app once built.
I have created a test solution which reproduces the problem @
Simply Press F5 and FileConfigurationSource will throw a FileNotFoundException when the Logger.Write() call is made in Page_Load. I assume in a perfect world this would work without throwing an exception. The path is correct, and the build shows the proper
content, but the path being resolved by File.Exists() is the path of the asp.net development web server (or visual studio, depending on how you look at it) and not from where the content is being served (e.g. your web app (or project) root.
I believe a fair method of resolution that would work for more people than it does right now would be:
1. If File.Exists(filePath) then return 'FilePath' unchanged.
2. If Exists() failed, and IsPathRooted() == true, then throw FileNotFoundException.
3. if !IsPathRooted() then concatenate the Executing or Calling Assembly Location (w/o the assembly name) with the content of 'filePath' to produce a 'new filePath', perform a File.Exists() on this 'new filePath', if it exists return this 'full path' to
4. If 'new filePath' from step 3 did not exist, you can optionally attempt to re-root it using the AppDomain Current Domain BaseDirectory, and if that fails, the GetExecutingAssembly for the primary app domain.
5. Lastly, no value should be returned from the function unless a call to File.Exists() succeeds on the value.
This may seem a but much, but without some modification it's broken for me. Currently I believe that if File.Exists() can't resolve the location you throw FileNotFound, and then if it's not a 'full path' (e.g. not rooted to a drive) you provide a rewritten
version that isn't always correct. A nice alternative would be if we could provide our own path resolver, but this is the equivalent of bloat given that .config files generally only find themselves in specific locations depending on your project/solution config
and build process, it would make sense if all standard locations were probed for a configuration file before FileNotFoundException was thrown.
Let me know if I can provide more info. My current work-around is to include my config directly within my Web.config, I have multiple environments to deploy to and wanted a different configuration source for each. Thus, rather than duplicating our Web.config
I wanted to duplicate our EntLib (and similar) configs and reference the environment by name (current it is a function of the build process which configs get referenced, which is problematic over time as the size of solutions get larger. EntLib seems like
it may offer an alternative to build-time management of run-time config, so that's my ultimate goal.