I have a C# custom appender library which needs to be used by several applications in different solutions which run in the same server. I have an addon installer solution that creates all the folders and stuffs which includes the custom appender library, which the other projects needs to use. Instead of adding this library into all the application's directory, I just want to let the each application's App.Config to point to this single custom appender library.
I have built a custom appender call MyCustomAppender in a library call MyCustomLibrary.dll.
Here is the xml code of one of the App.Configs:
<appender name="MyCustomAppender" type="MyCustomerLibrary.MyCustomAppender, C:\Users\Admin\Libraries\MyCustomLibrary">
It is not possible for me to put the path of the library because Log4net doesn't work this way. Is there a walk around for each application to point to C:\Users\Admin\Libraries\MyCustomLibrary.dll? to use the MyCustomAppender? The other applications needs to have 0 code changes, only their App.Config can be modified due the the reason this process needs to have minimal changes.
You can add the dll to the GAC on the machine your application is runnen. This will allow all programs to find the dll. BTW, coping the dll into the bin directory of the application will not change the code of the application.
Related
I have a console app and I am trying to implement log4Net for it.
I did the following steps -
added log4Net reference
Created Log4Net.config -
Created the LogHelper.cs class -
Added the following to the AssemblyInfo.cs
[assembly: log4net.Config.XmlConfigurator(ConfigFile = "Log4net.config", Watch = true)]
But the logging doesnt seem to work? Can someone suggest what needs to be done for the logging to work in th console app?
Make sure the config file is set to copy to the output directory.
In the log4net documentation for assembly attributes it says:
".. if you use configuration attributes you must invoke log4net to
allow it to read the attributes. A simple call to LogManager.GetLogger
will cause the attributes on the calling assembly to be read and
processed. Therefore it is imperative to make a logging call as
early as possible during the application start-up, and certainly
before any external assemblies have been loaded and invoked."
If it still doesn't work, enable log4net debugging as in this answer
I have an existing solution (multiple projects, one MVC web project) that I'm trying to wrap into an Orchard module.
All documentation says that the web csproj should be at the root under my module directory (eg Modules/MyModule/MyWeb.csproj).
However, I have an existing solution structure where the sln file sits at the top level and each csproj file (and project content) sits in its own directory (the standard solution structure when you build a multi-project app in Visual Studio).
Is there a way I can tell my Module.txt file that the Orchard Module csproj is under MyModule/MyWeb/MyWeb.csproj? I'd prefer to not restructure the whole solution.
Thank you.
Note: As a point of clarification, it is not ~/Modules/MyModule/MyWeb.csproj but ~/Modules/MyModule/MyModule.csproj. The Folder name of the Module must match the file name of the project (before .csproj). This is enforced by the Dynamic Extension Loader, which requires ~/Module/{ModuleId}/{ModuleId}.csproj. (A similar approach is required for themes.)
The only potential way to do this is to write a custom module that follows the above that contains a custom loader. Within your module, create your own implementation of IExtensionLoader, and register it with Autofac. However, I don't know if it would work; I've never tried.
You will probably have an easier time reorganizing your solution.
I have couple of projects embedded in a web app as jars. Each project has a log4j.properties file. When the web app is deloyed, which configuration file gets used and how to override the configurations in log4j.xml in a jar file. The jars are not web projects. They are more like service layer code. What is the order in which the log4j.properties file is loaded in the below scenario
Web-project
classes
log4j.properties
ProjectB.jar
com
log4j.properties
ProjectC.jar
com
log4j.properties and so on.
If your jars are separate web applications, each web application should use the one it first finds on the classpath (WEB-INF/classes).
You can pass a -Dlog4j.configuration=path_to_file setting to e.g. the tomcat startup to make sure that it uses the one you intend it to use.
However, this would then to my understanding and knowledge be the one that tomcat will use for every webapp that is deployed.
Question here is how you deploy your apps. Either all web applications in one tomcat in which case you probably want each web application to use a different log4.properties (or log4j.xml) or in the case where you specify one to tomcat, it should use the one you specify.
What it boils down to as far as i know: Either the first one found on classpath (remember: each web-app has it's own classpath) or the one you specify via the -D setting.
Just found this reference which i think nicely summarizes the main concepts of logging in tomcat and webapps deployed in tomcat: http://wiki.apache.org/tomcat/FAQ/Logging
If you need even more control over the log4j logging, you can resort to coding the log4j configuration in java. However, this would mean that you have to modify the source code and add code into it, which relates to infrastructure and relates deployment details to your application (not so nice).
If you set additivity to false in common packages at ProjectA, ProjectB and WebProject your log will not duplicate.
log4j.additivity.[logged package] = false
For example:
log4j.properies -> Project A, Project B
log4j.additivity.org.spring.framework = false
All org.spring.framework log will come from WebProject ignoring ProjectA and ProjectB.
Can I have multiple log4net configurations for the same program? Functionality similar to Spring's <import> element would be optimal. The idea here would to have multiple programs that have their own log4net configuration, as well as sharing a central log4net configuration file containing a shared error log (so that definition isn't repeated). Alternatively is this functionality possible with .NET Common Logging?
Related: log4net - configure using multiple configuration files
you can achieve this by using named repositories i think
log4net.LogManager.CreateRepository(repositoryName)
log4net.Config.XmlConfigurator.Configure(repositoryName, configFile)
then by using
LogManager.GetLogger(repositoryName,loggerName)
you can get the corresponding logger.
Not out-of-the-box. You must implement yourself the merging of different config files into a single XmlNode and pass this to log4net XmlConfiguratot.
An example is to be found here: http://www.kopf.com.br/kaplof/using-multiple-configuration-files-with-log4net
I'm using log4net logging in my software that consists of several applications.
I want to have one common library for this.
I created a library and put it in the conficuration file. In AssemblyInfo.cs placed attribute:
log4net.Config.XmlConfigurator(ConfigFile = #"c:\logging.xml", Watch = true)
It work for windows service, but in dosn't work for asp.net application.
It work in asp.net if delete attribute from common library and put in into global.asax. However, this leads to that section of the log4net configuration must be made in the windows service.
There is also a business process which causes our library through the
remouting. I want the logging was carried out there too.
Is there way around this?
In my opinion the library should not define where the configuration file is found. Maybe a better idea would be to have a helper method that allows you to configure log4net quickly; that method would take an optional parameter for the config file path and would try to load the configuration file from the specified path first and if that does not work fallback to some maybe the current folder, the application folder or even the web / app.config.
If you insist that it must be an absolute path then you need to give the IIS Application Pool user read access to this file. This way the configuration by attribute should work for services and ASP.Net applications. I do not understand what you mean by "remounting".