I am currently coding a very large project, I am near the end of the development stage and have sent out an evaluation version to the consumer so he can check for bugs and what not.
He told me that there was a large log file being created every time the application starts up.
After some investigation I found out that the log file was created using log4net via an external DLL which I use in my application.
I have searched a bit and found you can disable log4net logs through an app.config file and adding several values there, I tried this but with no success, the logs are being created no matter which value I use in the xml config file.
I have no access to the external DLL source code and I have searched for an xml configuration file that the DLL uses - but have not found anything.
I would like to disable log4net completely, the Logs are pretty useless for me since I use my own log engine, which i can configure any way I want it.
Thanks for any help
When you call for log4net you can specify the config file.
check the log4net initialization in your app to see where it gets the instructions.
another way is to configure log4net to use windows event log rather than a file and configure a limit on the log size.
You can specify the config file that log4Net uses; by default it is named log4net.config
If that's not the case, I would suggest firing up Process Monitor to check which file it is using.
[BTW, I would be slightly curious about using a third-party DLL that I didn't have control over.]
Log4net can also be configured programmatically. I wonder if the dll is doing that? If the dll is configuring log4net programmatically maybe you could use the log4net api to turn it off. I don't have a good example of how to do that now because I am on my phone.
Related
I have some external libraries that I am using that are logging to the console. I want these to log via log4net.
NOTE: I am NOT wanting to log to console from log4net, that should be straight forward.
What I have discovered thus far:
1) Console.setOut method allows using a different file stream.
1.1) Overriding memorystream seemed promising but there isn't a chance for raising an event to notify of changes
2) Writing to a file from Console seems like a work around, where I can read the file to update the UI textbox with new logs
3) FileStreams can autoflush, this means automatic updating of information. This sort of concept is similar to what I am after?
Whats the best way to get the console information put into log4net so that it can publish console log items the same way as log4net is configured? Currently my log4net puts logs into the eventlog, into a databinded wpf textbox, and into a file.
Personally don't know any other solution for this case other then you wrote:
ovewrite output of console pointing it to a file
read the file and add to a logger
To be notified about the change you can try to use FileSystemWatcher http://msdn.microsoft.com/en-us/library/system.io.filesystemwatcher.aspx.
Or if you don't want "real time notification", canopen file only for read and check with the timer if there is any row after last saved reader pointer position.
But I think, the first option is much easier.
Hope this helps.
As per my title, I would like to clarify: Is it advisable to update the config file while a .Net windows service is running?
What would be its implications, if this is possible?
Thank you.
Cheers,
Ann
There are other excellent answers here, but what are you asking? Are you asking about a service that you are writing? Or about someone else's Service.
If it is about a service you are going to write, then no, there is no automatic reload of the .config file when it is changed. You will either have to:
Restart the service to see the changes.
Write your service to use a FileSystemWatcher to see if the config file has been changed and then decide what you want to do with any or all the values that have changed.
If it is about someone else's service, you will need to ask them how it works based upon the above description.
This should have no effect on the running program. Configuration is loaded during application startup. If you want those new settings to take effect, you need to restart the service.
Edit:
More to the point of answering your question: When one creates a Windows service in .NET (I'm using Visual Studio 2010), an application configuration file is not created with it by default. By adding a New Item / Application Configuration File (App.config), you are creating a file that gets loaded at the start of the service. As commented below, there is no guarantee that it isn't being monitored during run time (unless you're the creator and you know that's the case), but this is not the common practice for App.config.
Under these standard conditions, it is advisable to make the changes, while running, after backing up the working copy of the config file. Then restart the service. If you broke it, revert back to your working copy.
You can do it but it comes with a cost,
do you want your service poll to know if there is any changes to the config file while it is running ?
Generally, I would not recommend polling for the content changes in the config file.
Application is a C# .Net 3.5 WCF Service.
I'd like during the build process to dynamically add some build information to the final binary and assemblies that can then be read programatically and sent back to the WCF client when it sends a GetVersionInfo request to the web service.
.Net assembly versioning isn't enough. I want to include additional string data that contains the state of the system at the time the application was built.
I'm thinking that I'd do this by adding a post build event to call a script to update the app.config file with the data I want. Does this sound about right, or should I be considering some other approach?
Update
I'd additionally like this string to appear in the "Special Build Description" property of the final exe. I.e. I'd like to right click on the file and see this information in the version tab for the file.
Thanks in advance.
I suspect a pre-build event may be more appropriate than post-build... have you considered adding a buildinfo.xml file (or similar) to be built into the assembly as an embedded resource? You could then load it with Assembly.GetManifestResourceStream. That way you don't need to worry about fitting in with existing files or anything like that - just overwrite buildinfo.xml with a new file in the pre-build step.
You have to decide how important it is that the information you want to exchange is tied to the executable file itself.
Updating the config file during the built is a workable model, but it places the information in a location where it could be altered by anyone with access and a text editor.
Updating information after a build in a compiled assembly is certainly possible, but it's fragile and breaks down if you ever decide to sign the assemblies. It's also a lot of work, since there's no built it support for re-writing assembly files in this manner.
An alternative you should consider, is creating your own custom assembly-level metadata attributes and assigning them during the build process. You could even place them in a separate code file (or append them to AssemblyInfo.cs) as part of you build.
You could also consider creating an embedded resource (an XML file, for instance), and retrieving it from the assembly manifest at runtime.
Either of the above approaches would require you to use a pre-build custom step rather than a post-build step.
Personally, I find the metadata attributes a convenient approach if there isn't a lot of data. Otherwise, I would consider using an embedded resource file.
I want to store settings for my C# application, such that default setttings can be easily shipped with my binaries and the end-user can change them using a simple text editor(or in some other simple way).
I seem to face several alternatives : a .config file, .settings file or a .resx file. What are the pros and cons of these?
Edit1: End-users are computer professionals mainly, so editing these files should not be much of a problem.
Edit2: The settings are something like connection strings, and some other parameters (mostly one-time stuff). Building some kind of GUI/API for changing them is not really an option. Also my application will not edit any of these values, so persistence through code is not required.
Yes, Project + Properties, Settings tab was designed to do this. Add your settings here, change the Scope to Application. That generates a app.exe.config file in your build direcctory, deploy it along with your EXE. Use Properties.Settings.Default.SettingName in your code to obtain the setting value. Your user will normally need admin privileges to edit the .exe.config file on the target machine to change the setting value.
The small print: settings do not work well for DLL assemblies, you have to merge the .config files by hand. When using the debugger, settings are retrieved from the app.vshost.exe.config file.
The .settings file is a helper file used by the IDE, ignore it. .Resx files store resources, they get compiled and embedded in a binary form in an assembly. They are not editable by the user.
I think you can have two ways of doing this.
For regular users, you can make a custom GUI that will make it simple for them to use.
For advanced users, they can edit the configurations using a text editor if it's stored in a text file (ini file, config file, etc..) or you can make an API.
The .settings file is typically used for user-specific preferences and configuration information (whereas the .config file is used for global settings for the application or anything that modifies the .Net runtime. Simply putting parameters in a .config file can alter the behavior of your application even without you writing a single line of code for it).
Check out the Settings article on MSDN for more: http://msdn.microsoft.com/en-us/library/aa730869(VS.80).aspx
Since the file will be modified by the users, I think using app.config is not a good idea. What if they break the file structure? Or set an invalid value? Probably your application will crash directly.
One of the solutions would be to use a custom XML file. You will then validate it when your application starts. XSD will probably be the more elegant way to do it, but you can also parse it directly and validate it in code. If the file is invalid, instead of crashing, you will try to solve the problem, and if impossible, display a pretty error to the user, explaining that there is an error in XML at line n, position n, which is [error description here].
If the end user is really going to be editing them, I'm not sure I would want them editing my app.config file.
You have another couple alternatives that you haven't included. You could use an old-school .INI file that is simpler for an end user to understand. You could also use the registry. I would recommend the INI file, unless your users are very savvy, in which case use the .config file.
The answer depends on the deployment method. For instance, if you are using ClickOnce and offer updates, you might encouter problems using Application Settings.
I believe the best way to go is to create a GUI, something that is most certainly suitable for novice users. Given that you already excluded that option, use John's suggestion (ini files).
Hey, I want to store application configuration data. Currently, I'm using INIs but they are too old and now I want to try something new. I'm on .NET platform using C#.
What solutions do I have? app.configs?
The scenario here is like that, I want to let other programs read the configuration data.
Yes, the various .config files (app.config, web.config, etc..) have replaced INI and, to a certain extent, the Registry as the preferred means of storing configuration data for your application.
Any program, .Net or otherwise, can read those files. .Net has the ConfigurationManager class and other languages can simply do XML parsing to get the values they need.
The standard approach with .NET is to use app.config files for application settings and user.config files for user specific settings (the location varies between XP and Vista though).
There's nothing to stop other programs reading the configuration data, you just need to have a configuration setting in the second (or third) application that tells it where to look.
The app.config would be the preferred way of doing things in .NET. Should work fine to read from other applications as well, as long as you give them the right path to the file. And it's just an XML file, so you can read it from non .NET apps as well.
If you're using Visual Studio, you can use Application Settings for this purpose. Just open the automatically added Settings.settings or create another one. They will be automatically available in Properties.Settings.Default and are stored as XML. You can also have multiple settings files for different purposes.
This is a Visual Studio concept rather than a .NET concept.
I often use an SQL table to hold my application settings. I create a singleton class, ususally called AppSettings, that I load with data from the table. The AppSettings class is then used to get the config values instead of directly accessing the config files. For ASP.Net apps, I instantiate the AppSettings class in the Application_Start event in Global.asax.cs.
Doing this gives me a way to allow the user to control some of the app settings, e.g. an email address for notifications. It also can simplify things when maintaining prod, QA, and dev versions of the app (assuming you have separate database instances for each)