I was reading Scott Gu's blog on ASP.NET 5.0 features and one of the new feature mentioned in the blog is to use json file as configuration and elimination of Web.config file.
I have few questions around that feature.
Assume I have following log4net configuration which was previously added to Web.Config in previous version of ASP.NET
Config file
<section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
<log4net debug="true">
<appender name="RollingLogFileAppender" type="log4net.Appender.RollingFileAppender">
<file value="C:\\TestProj\\TestLog.txt" />
<appendToFile value="true" />
<rollingStyle value="Size" />
<maxSizeRollBackups value="10" />
<maximumFileSize value="10MB" />
<staticLogFileName value="true" />
<layout type="log4net.Layout.PatternLayout">
<conversionPattern value="%-5p %d %5rms %-22.22c{1} %-18.18M - %m%n" />
</layout>
</appender>
<root>
<level value="DEBUG" />
<appender-ref ref="RollingLogFileAppender" />
</root>
</log4net>
How would one add sections in config.json ?
How would one convert above xml and add it to config.json?
Does 3rd Party library ( In my example log4net ) or users of the library have to add some type of custom conversion api to support json based configuration, in order to take advantage of new configuration feature provided in ASP.NET 5.0?
Recently I had the same problem with log4net. I managed to do it working as following:
Create log4net.xml file containing the configuration section for log4net
<?xml version="1.0" encoding="utf-8" ?>
<log4net>
...
</log4net>
You can put the file in the project root folder.
And in the Startup.Startup() method you can configure the log4net providing the xml as a configuration:
public Startup(IApplicationEnvironment appEnv)
{
// ...
XmlConfigurator.Configure(new FileInfo(Path.Combine(appEnv.ApplicationBasePath, "log4net.xml")));
}
I hope this helps.
Current versions of log4net don't support Json projects, so the config needs to be in a separate xml file.
Related
I have three separate projects, each with their own embedded logback.xml files. Each of these files includes a common logging config file in the user's home durectory:
<include file="${user_home}/loggingConfig.xml"/>
After the include, I have this specification:
<root level="error">
<appender-ref ref="${appender:-console}" />
</root>
This allows the user to configure their log levels and appenders, and have them applied by the core logging config file.
For example, in ~/loggingConfig.xml I have this line:
<property name="appender" value="file" />
But co-workers who prefer console logging leave that line out.
The problem is I would like to use different appenders for each log file. In otherwords, I would like to conditionally set a different appender based on which project is reading the customized config file.
I realize I could configure each project to read differently named config files, but I would like to eliminate the clutter and allow for shared configuration as well.
The documentation is a bit spare for advanced configuration, but I found that you can use the logback context name as a variable with conditional logging. So for each project I define a custom context name in the projects logback.xml file:
<contextName>project1</contextName>
etc...
Then in my ~/loggingConfig.xml file I can do this:
<property name="appender" value="file" />
<!--if condition='property("CONTEXT_NAME").equalsIgnoreCase("project1")'>
<then>
<property name="appender" value="file" />
</then>
</if-->
<if condition='property("CONTEXT_NAME").equalsIgnoreCase("project2")'>
<then>
<property name="appender" value="console" />
</then>
</if>
<if condition='property("CONTEXT_NAME").equalsIgnoreCase("project3")'>
<then>
<property name="appender" value="file" />
</then>
</if>
This can get a bit clunky, but in reality I am using this solution to configure properties used by a single appender for different projects, while still having a graceful fallback to a default value for projects that don't have their own conditional block.
In case this helps anyone else, this is how I set up conditional logback configuration with a property that can contain multiple appenders:
<root level="${logback.loglevel}">
<if condition='isDefined("logback.appenders")'>
<then>
<if condition='property("logback.appenders").contains("CONSOLE")'>
<then>
<appender-ref ref="CONSOLE"/>
</then>
</if>
<if condition='property("logback.appenders").contains("FILE")'>
<then>
<appender-ref ref="FILE"/>
</then>
</if>
<if condition='property("logback.appenders").contains("GELF")'>
<then>
<appender-ref ref="GELF"/>
</then>
</if>
</then>
<else>
<appender-ref ref="CONSOLE"/>
</else>
</if>
</root>
Is it possible to set the logger from configuration. I have a web app
using a framework. The framework is extensible and has the logger.
When I log, currently, the logger is set to the framework class.
Is it possible that I can configure my web app and set the logger for the web app to
loggerForWebApp and the logger for a console app (which is using the
same framework) to loggerForConsoleApp?
In addition to the root logger (which must always be there) you can have named loggers with their own appender-refs and levels.
For instance, you could have something like this:
<root>
....
</root>
<logger name="loggerForWebApp">
<level value="WARN" />
<appender-ref ... />
</logger>
<logger name="loggerForConsoleApp">
<level value="WARN" />
<appender-ref ... />
</logger>
In code, you would summon these loggers by their name:
var log = LogManager.GetLogger("loggerForWebApp");
Most definitely, and this is one of the great things about log4net: it can log out to a wide range of loggers.
For examples of the appenders, see here. Probably the most common one in use is the RollingFileAppender, but the ConsoleAppender can be very handy for console applications. Alternatively the TraceAppender can write out to the standard .NET trace listeners for further redirection (or display in the debug Output window in Visual Studio).
To create your own, implement IAppender.
details to follow
Is there a way to read a System.Config connection string in an MSBuild task?
Basically I have my connection string setup in a config file
<add name="MyApp.MyConnectionString" connectionString="..." />
And I would like to reference it in an MSBuild task like so ...
<Target Name="Migrate" DependsOnTargets="Build">
...
<Migrate Connectionstring="$(MyApp.MyConnectionString)" ... />
</Target>
There's an XMLRead task in the MSBuild Community Tasks Project, that uses xpath to pull out a value.
<XmlRead
XPath="/add/#connectionString"
XmlFileName="app.config">
<Output TaskParameter="Value" PropertyName="MyConnectionString" />
</XmlRead>
<Message Text="MyConnectionString: $(MyConnectionString)"/>
(note: totally untested)
I'm new to Castle Windsor and am confused about the order in the config file. This is taken from the GettingStarted1 sample. The HttpServiceWatcher class takes an IFailureNotifier implementor in it's constructor. However, no matter how I order the two components that implement this interface -- AlarmFailureNotifier and EmailFailureNotifier -- I always get EmailFailureNotifier. I know you can override which is chosen using parameters and a "service lookup" reference, but I thought that the order of declaration is used when other mechanisms are not.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<section name="castle"
type="Castle.Windsor.Configuration.AppDomain.CastleSectionHandler,Castle.Windsor" />
</configSections>
<castle>
<components>
<component
id="httpservicewatcher"
type="GettingStartedPart1.HttpServiceWatcher, GettingStartedPart1">
</component>
<component
id="alarm.notifier"
service="GettingStartedPart1.IFailureNotifier, GettingStartedPart1"
type="GettingStartedPart1.AlarmFailureNotifier, GettingStartedPart1" />
<component
id="email.notifier"
service="GettingStartedPart1.IFailureNotifier, GettingStartedPart1"
type="GettingStartedPart1.EmailFailureNotifier, GettingStartedPart1" />
<component
id="form.component"
type="GettingStartedPart1.Form1,GettingStartedPart1" />
</components>
</castle>
</configuration>
This was resolved with Castle 2.0 (that went RTM early last year).
The latest version of Castle is 2.1.1:
http://sourceforge.net/projects/castleproject/files/InversionOfControl/2.1/Castle-Windsor-2.1.1.zip/download
Castle's releases are always a bit tricky to find (they need to update their site). I always refer to the Project list:
http://www.castleproject.org/castle/projects.html
You want: MicroKernal/Windsor
I don't know which version you're using, but I believe this was a bug some time ago and it has been corrected in the build server version. Try that one and see what happens.
Also, you could use default components like this: Castle Windsor and default components
How can I inject the value of an appSettings entry (from app.config or web.config) into a service using the Windsor container? If I wanted to inject the value of a Windsor property into a service, I would do something like this:
<properties>
<importantIntegerProperty>666</importantIntegerProperty>
</properties>
<component
id="myComponent"
service="MyApp.IService, MyApp"
type="MyApp.Service, MyApp"
>
<parameters>
<importantInteger>#{importantIntegerProperty}</importantInteger>
</parameters>
</component>
However, what I'd really like to do is take the value represented by #{importantIntegerProperty} from an app settings variable which might be defined like this:
<appSettings>
<add key="importantInteger" value="666"/>
</appSettings>
EDIT: To clarify; I realise that this is not natively possible with Windsor and the David Hayden article that sliderhouserules refers to is actually about his own (David Hayden's) IoC container, not Windsor.
I'm surely not the first person to have this problem so what I'd like to know is how have other people solved this issue?
I came up with a solution for this eventually based on hints from various sources on the web. The end result though involved pretty much copying three classes from Windsor verbatim and modifying them just a little bit. The end result is up on codeplex for your enjoyment.
http://windsorappcfgprops.codeplex.com/
I originally wrote this code quite some time ago so it's based on Windsor 1.0.3 - yes, it took me that long to get around to publishing the result!
The code allows you to have this in your app.config (or web.config, obviously):
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key="theAnswer" value="42"/>
</appSettings>
</configuration>
...and access it from your Windsor XML config file like this:
<?xml version="1.0" encoding="utf-8" ?>
<castle>
<components>
<component
id="answerProvider"
service="Acme.IAnswerProvider, Acme"
type="Acme.AnswerProvider, Acme"
>
<parameters>
<theAnswer>#{AppSetting.theAnswer}</theAnswer>
</parameters>
</component>
</components>
</castle>
There's a working example in the solution.
I wrote a post about a similar case a couple of months ago. It uses a SubDependencyResolver to inject the appropriate parameters. In your case, you can just change DynamicConfigurationSettings for ConfigurationManager.