Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I need to use a logging library in my project and considering between Enterprise Logging Block vs NLog vs log4net. I found some links on the comparison but most of those are quite old and complaint about things like no new versions of log4net for long etc.
Anyone has suggestion regarding which one is better in terms of ease of use, ease of configuration, performance, scalability etc based on current data.
I just evaluated log4net and NLog for usage in a bigger project. Both have a similar interface and are highly configurable.
NLog seems to be better maintained: An incompatibility of log4net with .Net4 remained unresolved in log4net for quite a long time. Nlog comes with some more 'bells and whistles' like a NuGet Package and a Xml Schema for Visual Studio for editing config files.
In the end we decided for log4net because we measured a much better performance for log4net: A simple test, writing 10000 log messages to a file and to a network log viewer (Log2Console) showed a ten times better performance of log4net! We did no tuning in the config file, file and notwork logger were used with a minimal configuration. You should verify this for yourself with a typical logging setup of your project.
I personally like log4net. It's fast, stable and configurable (and it's really easy to extend with a custom appender or such).
I am not bothered by the lack of new releases - in my mind it just proves that the code base is stable and contains the features it should. After all, I want my logging to be stable above all.
Here is a slightly similar question, perhaps you can also use some of the answers from there.
You can postpone the decision "which logger to use" if you are using Common.Logging . This is a logging wrapper where you can configure wether logging should go to log4net, nlog, System.Diagnostics.Debug. I donot know Enterprise Logging Block and i donot know if there is a "Enterprise Logging Block" plugin for common logging.
Another difference that's often overlooked is that NLog is BSD while log4net is under Apache license. ELB is MS-PL (microsoft's open source version). That might not matter in most cases, just saying.
I find them all to be quite similar and capable. It's been several years since I used the Enterprise Library Logging Block, but even back then it was decent. NLog & log4net are both solid.
One reason to choose one over another may be 3rd party library integration. If you are using NHibernate or Quartz or other libraries that utilize log4net, for example, it may drive your choice.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am writing a software suite which is essentially composed of two separate applications in C# .Net using WPF. Although they may look a little bit different they essentially work like a lite version and a full version of the same software package. The full version contains all of the functionality of the lite version.
I had previously done this by creating two separate applications which share a class library where all the common user controls go. But i am now wondering if there is any better design for this kind of architecture.
I was even thinking of creating one application and at runtime let it decide which version it was going to work as.
Could anyone with any experience with this type of problem please point me in the right direction.
Keep it Simple
My rule of thumb is whenever possible keep solution as simple as possible. That being said I would use the same composition you are using.
Usually break up projects like this:
Application Logic: CompanyPrefix.ProjectPrefix.Core, CompanyPrefix.ProjectPrefix.Data...etc.
Applications : CompanyPrefix.ProjectPrefix.ApplicationType.App, so some examples :
CompanyPrefix.ProjectPrefix.Web.App
CompanyPrefix.ProjectPrefix.Console.App
CompanyPrefix.ProjectPrefix.Wcf.App
Since you have two Wcf Apps might want to do something like
CompanyPrefix.ProjectPrefix.Wcf.Lite.App
CompanyPrefix.ProjectPrefix.Wcf.App
So in this example both CompanyPrefix.ProjectPrefix.Wcf.App and CompanyPrefix.ProjectPrefix.Wcf.Lite.App point back to CompanyPrefix.ProjectPrefix.Core or wherever your business logic is.
About Dynamically Loading Assemblies
There is a way to dynamically load your libraries at runtime, but unless you're dealing with a modularized system of independent components would recommend against it.
If your heart is set on it there are a lot of resources on MSDN, would probably start here. Article about loading assembly into current application domain.
Come Up with a Checklist
One thing I find helpful is to come up with a checklist to help me make decisions in case I ever get stuck. Usually ends up being something like:
Does this have business value?
Does this make debugging harder?
What are the Pros and Cons of doing it a new way versus the way I have done this in the past?
This isn't my exhaustive list but explains the point. This can really help too when you have a group of people that are largely sticking with choices for personal reasons that don't have any grounding, as well as a tool to use when you get stuck to make a decision and go with it
Dealing with Application Logic Changing (Write Clean Code)
Coming up with an over-complicated "never need to recompile entire application again" is a mistake I have made in the past. You're still going to need to deploy and compile something.
Most important thing about dealing with changes in application is to
Have Code on Source Control (most important)
Write Clean Code
Write Tests
Write Documentation ( I know no one likes to do this )
Write some more Tests
What will consume most of your time when dealing with application changes is debugging so focus on reducing the amount of time you spend debugging not a amount of time you spend compiling and deploying
For Deployment setup Continuous Integration
If you have the ability to setting up CI would eliminate 99% of the hassle of changing the application. You lose a day or two setting things up for the first time, but it is well worth it.
Check out TeamCity and Travis CI
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Basically, the question is: Where (and in which format) should I store textual developer documentation associated with my Visual Studio projects?
To elaborate: XML comments are great, but they don't cover all use cases. Sometimes, you'd like to describe the class architecture of the project at a high level, add usage notes to your library or just leave any other kind of message to future generations of developers working on this project.
I'd like to add these documents directly as files into the Visual Studio project, to ensure (a) that they are available to the developer without further searching and (b) they are version controlled (using the same svn/git/whatever repository as the source code).
Currently, I add a folder _Documentation to the project and use text files, but I'm not sure if this is the best solution. Visual Studio does not have an option for automatically word-wrapping text1, and manually fixing line breaks after each change is annoying. On the other hand, Word documents don't work well with version control, and TeX is too much of a hassle to set up and teach on each developer PC.
Is there a well-established best practice for this?
1 I know that there's Edit/Advanced/Word-Wrap, but this only affects the display, not the file itself.
I just had the same issue - only I noticed that I was able to add a HTML-file. Once opened, simply switch to "Design" at the bottom of the screen.
You may want to change Build Action from 'Content' to 'None'
As it is a hard-coded HTML document, it is also possible to use inline pictures (e.g. a diagram)
Also for my purpose (programming guide, architecture description. database use examples) I opted to create a separate project (_Documentation) as a Windows Forms, as this will allow me (or a new programmer) to have a running example.
I use GhostDoc (visual studio add-on) for documentation of my project as I add classes, methods, properties etc: http://visualstudiogallery.msdn.microsoft.com/46A20578-F0D5-4B1E-B55D-F001A6345748
You have the option, in XML comments, to include a lot of data that you can then pick up with a tool like Sandcastle (site) and turn into an actual MSDN-style reference site.
I tend to use this method and just write long XML comments (MSDN comment tags) (where appropriate) using the <para></para> to generate paragraphs and explain any patterns, business reasons or architectural information necessary to future modifiers/developers. I also use it to give usage examples.
A good batch of tests (well written and named) can also really illuminate the purpose of code, acting as a spec.
I hope that might be a little informative in your research :)
XML Comments is best for documenting the particular method and not ideal for writing long conceptual content. Long XML comments could adversely affect code readability.
I liked Conceptual topic documentation feature of Sandcastle, we can create and store Conceptual documentation whether functional or architecture related and merge it with Code documentation (XML Comments). Markups which you can use in writing the conceptual topics are extendable which means we can even adhere to Enterprise templates.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I would like to try using an DI/IoC framework for the first time in a small-ish but growing project, and I don't want to disturb the project much by introducing bulky dependencies. The project itself is partly intended to be used as a library in other projects, and I don't want to trouble users with managing extra dependencies. It's also a matter of taste--I feel the size of a component should be proportional to the amount of services that I actually need. I hate to incorporate a bulky component with dependencies of its own, only to use a small part of it.
So, for .NET, is there a small DI/IoC framework that compiles to a single DLL with no dependencies other than standard libraries, that (if necessary) could be directly embedded in the assembly that uses it, and that emphasizes code-based/fluent (as opposed to XML) wiring? It must not require .NET framework 4.0.
I feel much the same as you do about IOC frameworks. I use IOC all the time, I just don't see the need for a Framework much.
Having said that, the one I'd use if I were to pick one up would be AutoFac
It's simple, easy to grasp, and feels lightweight.
I'd also suggest in addition to NInject that you look at Microsoft's DI Framework, Unity.
Any framework that you will introduce will eventually become a dependency of your app. Also, people have varied definitions of what lightweight is. Take a look at Unity, or StructureMap or Castle Windsor as they tend to be more popular. Scott Hanselman has a whole list, here. Take your pick.
Take a look at Ninject.
Try StructureMap.
The core StructureMap.dll is pretty small.
There are examples on the web about writing your own container, although they are very basic and would lack features provided by a more robust framework.
I work with a rather large system and we've manually injected everything. We make use of the abstract factory pattern to tidy up most of the injection/wiring and it's worked out fine.
DI Frameworks are plentiful. Before taking on an extra external dependency, take some time to consider if applying a different/new pattern would solve your problems.
edit: (possibly biased/unjust) Reasons I haven't used a DI framework:
If you use a DI framework, you have to ship the DI framework with your software. This can be a show stopper for some, and others might have to argue the merits of the extra dependency.
You still have to build constructors to take dependencies
And you still have to tell (or at least hint) at the DI framework what to use. The only major difference is your using the DI factory rather than your own.
As for building that factory, most refactoring tools can do 90% of the work for you with very few keystrokes.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
(subjective)
I'm looking for what your using to perform logging in your application. This log4net thing is giving me headaches. Is there a better answer out there or is everone just homebrewing a solution? I know the System.Diagnostics.Trace subsystem is quite capable should I layer on this?
NLog is probably the other big player in this area. Also, There is an application bloc in entreprise library that is dedicated to tracing and logging.
Why not use just the .NET classes for logging?
With Custom-Listeners you can do almost anything for logging, can apply filters, spread your logs to multiple targets, databases, files, network, whatever.
Just watch out what the .NET-Framework is capable of, you'll be surprised.
There are quite a few .NET logging libraries and tools out there, here's an extensive list:
http://www.dotnetlogging.com/
You might also want to take a look at our .NET logging product SmartInspect, which provides rich logging capabilities (in contrast to the text-only logging features of most other logging tools) and comes with a log viewer and optional log server application.
Try Elmah its pretty easy, mind you log4net is not so bad once you get your head into it....
What actually are your headaches?
We use the Enterprise Library exclusively in our corporate environment (Logging Block). And I've recently started to use Log4Net on personal projects.
From experience, the Enterprise Library, albeit powerful, is a mighty pain to get up and running. Not only from just trying to figure out which dll's to use, but the configuration can become unwieldy.
On the flip side, I've found Log4Net to be extremely easy and you can be up and running in no time; quite literally in less than an hour.
Granted I'm a MS fanboy (ok, not really, but they are the reason I can make a living) and typically go with MS. However, I've made the recommendation to migrate to Log4Net at work. The simplicity of it really is refreshing.
Take a look at Common.Logging. It works with all major logging frameworks (system.diagnostics, log4net, nlog, entreprise library) and allows you to switch logging frameworks from configuration.
From my personal experience - I've used .NET tracing in a corporate environment which didn't allow us to use opensource, and after we perfected the rolling file tracelistener, it was quite easy to use. Now I use log4net and it's pretty nice, but takes some getting used to.
I know this question is too old and you are looking for alternative to log4net, but believe me log4net is the best logging solution and is most commonly used and also provides large range of log listeners than any other logging framework. Moreover you can even implement a custom appender along with the in-built appenders. For those who are having trouble configuring log4net can use following post which describes step by step guide to make it work.
Log4Net section in Web.Config generates Error
happy logging:)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Lately I've been working on a few little .NET applications that share some common code. The code has some interfaces introduced to abstract away I/O calls for unit testing.
I wanted the applications to be standalone EXEs with no external dependencies. This seems like the perfect use case for static libraries. Come to think of it third party control vendors could benefit from this model too.
Are there some hidden nasties with static libraries that I've missed?
Is there any reason why the C# designers left them out?
Edit: I'm aware of ILMerge but it doesn't offer the same convenience as static libraries.
.NET does in fact support the moral equivalent of a static
library. It's called a netmodule (file extension is usually
.netmodule). Read more about it in this blog post.
Beware that it isn't well supported by the Visual Studio
build tool chain. I think extension methods are a
problem as well. ILMerge is the better tool to get this
done.
This is not directly related to C#, but to the whole .NET umbrella. Sure, it's possible to merge assemblies using ILMerge, but alas it's still a research project, but at least its license permits use for commercial endeavors. Other than that, the runtime (CLR) cannot be coalesced into a single executable, the target platform still needs .NET to be installed.
Edit:
I was typing this before you edited your post with ILMerge. I might be wrong but there is not additional benefits from avoiding the .NET-style dynamic linking at runtime. There's nothing wrong with putting the satellite assemblies together with the executable. Microsoft doesn't recommend putting them in the GAC.
Using static libs has the drawback that it is not patchable by the runtime provider (MS).
For example if you use static MFC libs and a securify issue or other bug is found in the MFC static libs, MS can not patch it (the code is already in your executable). Using shared Dlls allows for an easy patch at OS level without you caring about that.
Of course having shared libs has a small drawback: a dependency is taken and they must be installed on the system.