问题
I am using Microsoft Enterprise Library 5.0 Optional Update 1 for logging. I've got a declared section in my app.config file as follows:
<loggingConfiguration name="LLamasoftLoggingConfiguration" tracingEnabled="true" defaultCategory="General">
<listeners>
<add name="XML Trace Listener" type="Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners.XmlTraceListener, Microsoft.Practices.EnterpriseLibrary.Logging, Version=5.0.505.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
listenerDataType="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.XmlTraceListenerData, Microsoft.Practices.EnterpriseLibrary.Logging, Version=5.0.505.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
fileName="%ALLUSERSPROFILE%\CompanyName\AppName\Diagnostics\ErrorLog.xml" traceOutputOptions="None" />
</listeners>
...
</loggingConfiguration>
When I run the application and get down to using the logging, e.g.,
logWriter = Microsoft.Practices.EnterpriseLibrary.Common.Configuration.EnterpriseLibraryContainer.Current.GetInstance<LogWriter>();
logWriter.Write(logEntry);
I'll get a DirectoryNotFoundException with the text: Could not find a part of the path 'D:\Project\Application\bin\x86\Debug\%ALLUSERSPROFILE%\CompanyName\AppName\Diagnostics\ErrorLog.xml'.
When I use an absolute path like 'C:\ProgramData\CompanyName\AppName\Diagnostics\ErrorLog.xml' it works.
I see a number of references saying I should be able to use environment vars in the log file path but, no matter which I try, they get appended to the current execution directory path. The references also say that the logging system will create the folder if it does not exist but I have to ensure that it exists.
This is my first use of the Enterprise Logging application block so I don't know whether the behavior has changed between versions and if this one just has these quirks. For now, I've hard-coded the path into my app.config file but for the final version this should be dynamically determined.
Suggestions appreciated.
回答1:
I was hoping to see that someone answered the question before I got back into work this morning. Seeing no answer, I thought I would spend just a couple of minutes more on the problem since I had only a smelly workaround in place.
I installed the source code supplied with the library (thank you, Microsoft), built the solution and examined the code. The short answer is, the expansion of the environment variables will only occur with the file names provided to the FlatFileTraceListener. While it seems reasonable to expect that the file-based usage of the XmlTraceListener would do the same thing, it does not. Without the expansion of the environment variables, you'll see the behavior as I described above.
If you want to change the behavior, look into the Logging.2010 project and examine the FlatFileTraceListener.cs and XmlTraceListener.cs code in the TraceListeners folder. You'll see a call to a helper, EnvironmentHelper.ReplaceEnvironmentVariables(string fileName), used with the flat file implementation and not with the xml (file) implementation. It looks to be an easy change.
Hope that saves somebody else a few hours of time.
回答2:
The issue of "environment variables are not expanded when used in filenames" can be solved by adding the latest entlib version 5.0 to your solution. I downloaded it by:
- Right click on your solution (VS 2013).
- Manage NuGET Packages.
- Search for entlibcontrib 5.0 logging extension block.
- Add it to all your projects.
Then the logging class was able to parse the %USERPPROFILE% string in the file name and I was able to see my log file being created in the userprofile folder.
来源：https://stackoverflow.com/questions/9099994/enterprise-logging-not-translating-environment-variables-in-xml-trace-listener-f