First of all, apologies for the subjective sounding title. This is intended as a direct question.
At present I am working on a suite of tools:
A C# Windows Service, to primarily
maintain an Oracle database.
A C# Windows Service, (which will be
used on multiple node sites) to
process content of the database.
An ASP.NET web interface to
facilitate management of the overall
"system"
Currently the tho Windows Services have been developed as Console Applications (to ease debugging/development) and I am in the midst of converting these to Services. After testing for a couple days now with these services, I'm finding that I would like to increase the granularity of my logging. I'm finding that I miss Console.WriteLine() and I would like to provide an alternate log source like a flat-file for this type of output. This has lead me to think, "Should I be using a framework, or have I got enough?"
The reason I have mentioned the aspects I am developing is to provide insight to my situation. A "Core" DLL has been created, common across all components, abstracting the interaction layer between the applications and database. It is within this DLL that a class has been created which will attempt to "log to a table in the database" else on fail "log to local Event Log". This is it, that's the extent of logging.
Throughout the aforementioned tools, there are multiple instances of logging not dissimilar to:
Log.LogError("Code", e.Message + "\n" + e.StackTrace);
Although quite basic, this method does make use of reflection to Identify the source of the error.
My Question
Looking at my current logging solution it appears "sufficient" in terms of what it does and how it is integrated with all my solutions. However, I've been looking at logging frameworks (Notably log4net) and their features impress me. The ability to, if needed in the future, add another output format (such as an SMTP server) sounds kind of cool to me! :)
What I would like to know are the benefits of moving to a framework (like log4net)? The extent of how much I will have to adapt my code? Whether or not I am just looking at the greener grass on the other side? And finally, but probably most importantly, am I doing the right thing? Should I just add the ability to my Log class to "LogDebug" and be done with it? The last thing I would want to do is completely overhaul my suite, just for a "basic" feature, but if there are other benefits (to design, reliance, good practice? etc.) I'm interested.
Thanks,
Yes. Using an existing, proven logging framework (such as Log4net) is a good idea.
Log4Net is configurable at runtime (great for tracking down issues in production code).
As a commenter pointed out, it's also very simple to use.
Proper logging is especially beneficial when running code on multiple remote systems, as far as I recall, log4net will let you send your logs to a remote syslog server without much coding overhead (meaning you can view your logs from all machines in one centralized place) doing this will massively reduce the time it takes you to get information relating to a bug or problem with the system, and should also give you an indication of how prevalent the issue is.
As mentioned in other posts, log4net also allows for multiple appenders and multiple log levels, so determining where you want certain log information (i.e. in a database or in a local flat file, hey log4net even lets you spit logs out over telnet) to be stored is an absolute doddle.
As for implementing it, there are several good sites talking you through the setup. How you actually make use of the logging objects that log4net gives you is an architectural choice, but you could simply change the constructor of an object to take a log4net object and from within this object, just use the log4net object as you would Console.WriteLine.
I find the tutorial series here particularly useful, and it'll also go in to more depth than I can here about the benefits and the different ways of configuring log4net.
Yes, you definitely want to use a logging framework. A logging framework will allow you to:
Set the logging levels for the different logger instances.
Set the "appenders" or output for each of the different logger instances.
Perhaps, more importantly, if you use a logging framework, it is very easy to swap out one implementation of the logging framework for another (perhaps a null implementation that simply discards messages); whereas, if you write all your logging statements, directly, swapping out the implementation will be a nightmare.
I think you should use Log4net, simply because it's always better to reuse than to build your own thing. log4net has been used by a lot of developers and are pretty matured.
Think about your maintenance prospect; one or two months down the road, you might need to tweak your custom logging class a bit, to add some multithreading support etc. And when you are fixing the bugs arose from your logging class, you will miss Log4net.
Well one of the bigger benefits is not having to maintain the code yourself. Most of the time, logging frameworks have a lot more functionality than your own solution. Because they are so focused on logging, those frameworks usually are pretty complete in the both functionality and ways to implement it. And then there's reliability; there's nothing worse than a logging framework that's not logging anything because it's bugged. ;)
Take for example ELMAH for ASP.net applications. It also includes notifications, exports to various target formats, etc. Things that are pretty handy but you'll never build yourself unless you really need it.
How many changes to your code are needed obviously depends on both your code and the framework of choice. It's hard to say anything about that.
I am going to give a shout out to NLog (http://nlog-project.org/home) as it doesn't suffer from the 'Straight Java Port - then rewrite' syndrome of most oss .Net libs.
Some key benefits for us were the very fast Logger.IsFooEnabled (volatile read) and the overall performance of the system.
To each its own though, but I personally prefer NLog for my projects (and some of my clients too).
Cheers,
Florian
The advantage of using a good logging framework like Log4Net is that they have a small impact upon your code in terms of lines of code that you have to alter (in other words you only have to alter each existing logging line).
Also, if you are concerned about altering your code if you change frameworks, or if you feel you want to roll your own, then you could always create your own interface to a logging framework. Then you only ever have to change your code in one place after that.
I think sysadmins expect services to log to the application event log in windows.
Look up System.Diagnostics.EventLog, although log4net will write to that too..
The initial statement in the log4j website might help in some of your questions, the underlying principles are the same of log4net:
With log4j it is possible to enable
logging at runtime without modifying
the application binary. The log4j
package is designed so that these
statements can remain in shipped code
without incurring a heavy performance
cost. Logging behavior can be
controlled by editing a configuration
file, without touching the application
binary.
Using a logger hierarchy it is
possible to control which log
statements are output at arbitrarily
fine granularity but also great ease.
This helps reduce the volume of logged
output and minimize the cost of
logging.
In this case there's clearly no need to reinvent the wheel. Most Logging frameworks are somewhat straightforward, so the extend of changes will most likely depend on the size of your existing programs.
if you write your logger class properly it will be easily expendable to any of your needs. Any framework could impress you with many features but another framework is another variable in your debugging process as it can give you an error that does not exists or can make an error by itself in combination with your application. If you are ready to make beta testing for open source software project this is fine...
In your place i would write log class with ability to extend it features you find interesting to you project based on the list of features known frameworks have. I don't see any problem to log something to file and then send it over smpt, just one small function does the job.
Moreover, you can write your own class which will be pretty abstract and put your basic code in there, if you will ever need to use external framework for testing you class would be able to use it with minimal impact on code. Just take a look how there frameworks are implemented on the code level.
think of that you will need to learn how to properly use these frameworks when your only needs for now to log very small part of it...
Related
I am working on a project using asp.net and c# and I need to pull in something like wkhtmltopdf. I realize that there have been several good wrapper classes written to simplify calls to the dlls using c#. But is there a reason why I should not invoke the executable directly? Is there any performance or security gain from using a wrapper library?
Although, my specific need now is to use wkhtmltopdf, I have had the same question in the past when using libraries like imagemagick as well.
It's a matter of preference. By using the wrapper classes you mentioned, the work that you do implementing components that you may not be so familiar with is reduced, thereby freeing up your valuable time to concentrate on those aspects of the application where perhaps you can make your strongest value-add, such as the overall application architecture and design, or perhaps the application's business logic.
If you choose to write all the code yourself, then you may find that you're a less productive developer than your competition.
And, as #UweKeim points out in his comment, performance may be a factor as well. If the wrapper code does not perform to your needs, you may well need to bypass it and go straight to the component/code library you're calling.
It's important to strike a balance between use of code that others have written, versus your own. Important factors are things such as, how well is the 3rd party code written, how well is it supported, how well it performs, etc. Choose wisely!
This question is strictly about the inefficient architecture of an existing system that needs to be rebuilt. It solicits validation from fellow developers who have had experience with managing such awkward systems. I have tried to abstract it as best as I could below.
The application caters to a very complex need and it delivers very well. The problem is that internal plumbing makes code management and scalability a nightmare. The little information I can share about context includes the fact that we need to treat code as a data commodity. In other words, the system can only function if implemented classes are added to it on a continuing basis.
What the application delivers to end-users is not data, but an [Action] that requires a code execution context. So the application has to execute some code on the target system in order to deliver what the user expects. Now these expectations are not known at compile-time and new ones need to be added almost on a daily basis. That means, developers keep adding [Actions] to the system regularly.
The existing system links to these [Action] classes statically! Not only does that make code management a nightmare, but also requires a recompile every time an action is added.
My first instinct was to have the system dynamically link to assemblies at runtime where each assembly would contain a bunch of actions. This would be akin to adding extensibility capabilities to the application. I thought about the MEF framework but it just did not feel right.
The only alternative I can think of is storing each action in the database as either source code or a compiled module. Each has its own trade-offs such as storing as source is less secure but gives me more control over code review and continued maintenance. Storing as compiled has the benefit of server-side assembly signing.
I would appreciate some advice about how to structure a system like this.
I don't think you need a more flexible architecture, but a more flexible software process. Adding new functionality on a daily basis is what most developers do. That doesn't a valid argument for a plugin system.
You don't need a plugin architecture. You need a good software development methodology, such as the agile processes (such as Scrum and XP), and make sure you be able to do this:
Let developers build new components in braches.
After thorough testing, merge new functionality to the main branch.
This way the main branch always has production quality and you can roll out new versions each day using continuous integration and continuous delivery.
I'm wondering if there's any way of having some sort of Aspect-Oriented way of setting up logging of C# code. Or if the code could be instrumented for automatic logging.
At the moment the code is riddled with Log("Enter method XXX") and Log("Leaving method XXX") which make maintenance really tedious.
Ideally I'd like to have something that does the logging automatically the same way as the libraries are instrumented for profiling.
The next best thing would be to have some custom attributes maybe that I can tag my methods with. These would put some logging code on entrance and exit of the method.
And if the solution were compatible with the EntLib that would be perfect :)
Cheers.
If you're using the Enterprise Library, you have everything you need. Take a look at this article: http://www.codewrecks.com/blog/index.php/2009/01/31/unity-and-aop-in-enterprise-library/
You could use Log4PostSharp. I am not sure though what the future of this looks like as PostSharp went commercial.
What your referring too is a cross cutting concern, and not only affects your application but other applications that you might install at your establishment. The Enterprise Blocks are great and the inversion of control principal does help a lot with extracting repeating code from out of the system. However there is no way of logging without deciding some place in your code that you wish to record the event. for example exceptions, logging in, logging out, db actions, restricted actions etc. If you go the Enterrpise route its all done through configuration files and policies.
In the solutions I have provided, I have moved the logging functionality outside of the application space and it now sits aside every piece of code that I develop, ready and waiting to do the logging for me. On the last project I used a combination of Enterprise Blocks and Couchdb. Couchdb really helps with the aspect side as it works using REST and Json without involving itself too much in your application writing an interface to the log files is just a matter of a bit of HTML, it really is a fire and forget type affair, until that bad ol day when you need to scour the logs :)
The only problem that I have seen in applications where you automate the logging is that you use some sort of delegate process and pass things into them, which increases stack space. But this is so trivial that its beyond reason.
Program to interfaces and defined interfaces and you should be okay.
I remember something regarding Interceptors / Proxying to log entry/exit of methods.
Stack Overflow question - How do I intercept a method call in C#?
and check out this blog (ref'd in the same question) - http://madcoderspeak.blogspot.com/2005/09/essential-interception-using-contexts.html
We are in a situation whereby we have 4 developers with a bit of free time on our hands (talking about 3-4 weeks).
Across our code base, for different projects, there are a number of framework-y type of code that is re-written for every new project that we start. Since we have some free time on our hands, I'm in the process of creating a "standard" set of libraries that all projects can re-use, such as:
Caching
Logging
Although these 2 above would rely on libraries such as Enterprise Library, each new project would write its own wrappers around it, etc, so we're consolidating all these code.
I'm looking for suggestions on the standard libraries that you built in-house that is shared across many projects.
To give you some context, we build LOB internal apps and public facing websites - i.e. we are not a software house selling shrink-wrap, so we don't need stuff like a licensing module.
Any thoughts would be much appreciated - our developers are yearning to write some code, and I would very much love to give them something to do that would benefit the organization in the long run.
Cheers
Unit Testing Infrastructure - can you easily run all your unit tests? do you have unit tests?
Build Process - can you build/deploy an app from scratch, with only 1 or 2 commands?
Some of the major things we do:
Logging (with some wrappers around TraceSource)
Serialization wrappers (so you can serialize/deserialize in one line of code)
Compression (wrappers for the .NET functionality, to make it so you can do this in one line of code)
Encryption (same thing, wrappers for .NET Framework functionality, so the developer doesn't have to work in byte[]'s all the time)
Context - a class that walks the stack trace to bring back a data structure that has all the information about the current call (assembly, class, member, member type, file name, line number, etc)
etc, etc...
Hope that helps
ok, most importantly, don't reinvent the wheel!
Spend some time researching libraries which you can easily leverage:
For logging I highly recommend Log4Net.
For testing nUnit
For mocking, Rhino.
Also, take a look at Inversion of Control Containers, I recommend Castle Windsor.
For indexing I recommend Solr (on top of Lucene).
Next, write some wrappers:
These should be the entry point of you API (common library, but think of it as an API).
Focus on abstracting all the libraries you use internally in your API, so if you don't want to use Log4Net, or Castle Windsor anymore, you can by writing well structured abstractions and concentrating on loosely coupled design patterns.
Adopt Domain Driven Development:
Think of API(s) as Domains and modular abstractions that internally use other common APIs like you common Data Access library.
Suggestions:
I'd start with a super flexible general DAL library, that makes it super easy to access any type of data and multiple storage mediums.
I'd use Fluent nHibernate for the relational DB stuff, and I'd have all the method calls into the you data access implement LINQ, as it's a c# language feature.
using LINQ to query DBs, Indexes, files, xml etc.
Here is one thing that can keep all developers busy for a month:
Run your apps' unit tests in a profiler with code coverage (nUnit or VS Code Coverage).
Figure out which areas need more tests.
Write unit tests for those sub-systems.
Now, if the system was not written using TDD, chances are it'd be very monolithic and will require significant refactoring to introduce test surfaces. Hopefully, at the end of it you end up with a more modular, less tightly coupled. more testable system.
My attitude is that one should almost never write standard libraries. Instead, one should refactor existing, working code to remove duplication and improve ease of use and ease of testing.
The result will be very much like a "standard library", except that you will know that it works (you reran your unit tests after every change, right?), and you'll know that it will be used, since it was already being used. Otherwise, you run the risk of creating a wonderful standard library that isn't used and doesn't work when it is used.
A previous job encountered a little down time while the business sorted out what the next version should be. There were a few things we did that helped
Migrated from .net reoting to WCF
Searched for pain points in the code that all devs just hate to work with and refactor them
Introduce a good automated build system that would run unit tests and send out emails for failed builds. It would also package and place that version in a shared directory for the QA to pick up
Scripted the DB so that you can easily upgrade the database rather than being forced to take an out of date copy polluted with irrelevant data that other devs have been playing with.
Introduced proper bug tracking and triage process
Researched how we could migrate from winforms to wpf
Looked at CAB (composite application) or plugin frameworks so configuration would get simplier. (At that time setup and configuration was a tremendous amount of time)
Other things I would do now might be
Look at Postsharp to weave cross cutting concerns which would simplify logging, exception handling or anywhere code was repeated over and over again
Look at Automapper so that conversions from one type to another was driven by configuration rather than changing code in many places.
Look at education around TDD (if you dont do it) or BDD style unit tests.
Invest time in streamlining automated integration tests. (As this one is difficult to set up and configure manually it tends to get dropped of within SDLC)
Look at the viability on dev tools such as Resharper
HTH
We have an in house winform application that is used by about 20 users in my company. It's a real pain having to send the users a new msi when the application has changed in scope and I would like to have the users prompted from the application as to whether they would like to update their copy. My thoughts are that the source of the application would be on our company server and that the application would look to a database to see if updates area available. Aside from that I don't know where to go from there. Has any one done anything similar to this or does any one have any recommendations on how I should implement this.
Here's an open-source solution I wrote to address specific needs we had for WinForms and WPF apps. The general idea is to have the greatest flexibility, at the lowest overhead possible.
So, integration is super-easy, and the library does pretty much everything for you, including synchronizing operations. It is also highly flexible, and lets you determine what tasks to execute and on what conditions - you make the rules (or use some that are there already). Last by not least is the support for any updates source (web, BitTorrent, etc) and any feed format - whatever is not implemented you can just write for yourself.
Cold updates (requiring an application restart) is also supported, and done automatically unless "hot-swap" is specified for the task.
This boild down to one DLL, less than 70kb in size.
More details at http://www.code972.com/blog/2010/08/nappupdate-application-auto-update-framework-for-dotnet/
Code is at http://github.com/synhershko/NAppUpdate (Licensed under the Apache 2.0 license)
ClickOnce.
If it's a fairly simple program (not many dependencies) consider keeping the program on a network share have have users run from there.
The most popular solutions with graphical update prompts are AutoUpdater.NET and WinSparkle. For a more powerful solution, take a look at Google Omaha.
Squirrel is definitely worth a look