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:)
Related
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 2 years ago.
Improve this question
My case is - I'm developing a system that help a car service to communicate with their customers and vice versa. There will be two products - a mobile app written in Xamarin.Forms and a web page in ASP.Net - both doing same things more or less, an alternative. The database will be hosted on SQL Server. And now I'm confused about the "middle" layer. I have been reading a lot about WCF and WebAPI and I still can't figure out which is better for me. Any suggestions for this scenario?
"Better" is always a hard question to answer. So, that's my disclaimer.
WebAPI is currently pretty standard, and quite easy. It allows for simple REST api's - although these are very doable with WCF as well.
The main difference between WCF and Web API
Web API
is, well Web (HTTP) - almost every language supports it, it's relatively light weight.
WCF
It's big - HTTP is just one of the options for binding. It's ideal for enterprise wide connectivity solutions. For example - reusing your logic for HTTP bindings and or message queueing.
One nice feature of WCF is that, at least for C#, it generates client libraries and models for you. It comes with Visual Studio (note: see warning). For the WebAPI, you might need to create the client libraries yourself - which basically be a lot of HTTP calls.
If you want it simple - WebAPI has very good support and can be implemented easily from any language - the clients and models are pretty straight forward - but usually you do need to code them yourself, unless you use OpenAPI spec and some toolkits.
Warning
The generated WCF libraries, might or might not be compatible with the framework (Mono, Xamarin, Core, etc.) you are using. As #Dai mentions, the WCF client library generation might be outdated. Although I do not know if there are more open source tools available to extract clients from the WSDL. So, you should try if your client is compatible first.
For Web API client generation, you can look at tools like Swaggerhub. Do note: you need to define the spec in your application (or provide it explicitly)
See: https://swagger.io/tools/swaggerhub/
The advise (obviously just an opinion)
If you don't need the full package of WCF, the extensive binding capabilities and such, I would go for the WebAPI variant.
If you combine it with Swagger (OpenAPI spec), you'll get a pretty open and easy to use API available for a broad variety of languages.
For more info on swagger/swashbuckle: https://learn.microsoft.com/en-us/aspnet/core/tutorials/getting-started-with-swashbuckle?view=aspnetcore-3.1&tabs=visual-studio
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.
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 7 years ago.
Improve this question
I've been looking for a simple key/license system for our users. Its partly to stop piracy (avoid users from sharing the application around) and the other half to track the number of 'licensed users' we have. I have already read a few good suggestions on SO but I'm curious as to how people have implemented the 30 day evaluation criteria.
Do you generate a key that stores the date somewhere and do a comparison each time or is it a little more complicated - deleting the file/removing the registry shouldn't deactivate.
Are there any example implementations out there that can give me a head start? The irony is that our PM doesn't want to license a third-party system to do it for us.
This is for a Windows Forms application.
Have you checked out the Rhino-Licensing project by Ayende Rahien. You can also see his blog post about licensing a commercial product which led him to develop this solution.
There are two separate challenges: i. How do you prevent a copied app from running. ii. How to prevent users from ripping out/bypassing your prevention scheme. The first one is usually done by taking a hard to copy signature of the user's system (e.g. Hard Drive ID + Processor ID + RAM, etc) and using it as the seed/key AND activating it on-line by calling "home".
The Second issue is harder to do in .Net since the source code can be in someway extracted and recompiled to exclude your protection system. The key here is to make it cheaper to buy the license than to remove the protection at the user's end. You may find that for most products, the suggestion to use a customized engine to encrypt your product libraries that also contain your copy-protect and decrypt it at initial run-time, might be enough.
I am not sure you can actually protect a .NET - There may be commercial solutions that do the trick. The reason is .NET code can be seen through Lutz Roeder (Thanks Jasonh for the heads up) Red Gate's Reflector (It was formerly by the named guy above). The best way to deal with it is to look for code obfuscation which makes reflecting more trickier, I can point you to one place I know of that does this for free - Phoenix - NtCore.Com.
The more esoteric solution would be to create a .NET hosting environment in C++, load the binary image (which could be encrypted) and the hosting environment than undecrypt it in memory - have heard of that theory but not sure how that would be done in practice. Please do not use your own protection scheme as there could be a weakness.
Someone once said - "Security through obscurity"....
Hope this helps,
Best regards,
Tom.
I worked on a project that handled this by putting some critical functionality (for example data storage, reporting, or payments) on an external server we ran, and requiring the user to log in to this server to get the functionality.
Customers can make backups, share, or run the application locally, but to access this critical function they have to type a password in to our application and connect to our server. Customers knew the password allowed changing their data, so they would not want to share the password with other people.
This was handy because we do not care how many copes of the application are out in the wild, we only track server connections. We included machine-identifying data like MAC address in the connection data, so we can track which machines are connecting.
I'm not just saying this because my company sells the OffByZero Cobalt software licensing solution for .NET: your PM should know that software licensing is very hard to get right, and if you roll your own, you'll be supporting it for the foreseeable future.
Take a look at the article Developing for Software Protection and Licensing; it explains how to choose a solution, why you should obfuscate your application and gives a number of tips for structuring your code to be harder to crack.
In particular it makes the point that the vast majority of companies should outsource their software licensing, as it makes no sense to spend developer time on building and maintaining a complex system that isn't your core business.
What is more important to your company: adding an important new feature to your product, or tracking down a peculiar permission behaviour on an ancient version of Windows that's clobbering your licensing system?
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 8 years ago.
Improve this question
Scenario
I have recently graduated from university with a degree in Computer Science.
My degree mainly focused on C#.
I want to learn more and get better at what I do.
I notice a lot of companies always want their developers to know and use 3rd party tools.
Question
If I was developing C# Windows Forms applications, what 3rd party tools/libraries/controls etc. would be of use to me and for what reason?
The answer to this question depends on how you define "3rd party tools". I usually take that to mean products from companies other than MS but excluding free open source software. When it comes to 3rd party products (for-profit) I cannot think of any common products that I've used or been asked to learn over the last decade that I've been doing .Net development. Most MS shops I've worked with turn to MS solutions (for good or ill depending on your personal view).
That said, in recent years the number and quality of the various FOSS solutions out there has risen dramatically. I use the following whenever I can:
Logging: log4net
Inversion of Control Container (plus more): Castle Windsor
ORM: NHibernate
Unit Testing: NUnit
Mocks for unit testing: Rhino Mocks
For most of these projects there are many other options, these are just my current favorites. Learn to use these (and WHY they are needed) and you'll be many steps above the average .Net developer (sad but all to true).
The DevExpress and Telerik controls are pretty popular, but not free.
Some 3rd party .Net component providers that I've seen used in companies most often:
Telerik
Infragistics
They are not free. These kinds of providers offer large libraries of controls that you'd pick from to achieve your specific goals.
Many good suggestions here, I would also add a few other categories of tools:
Software configuration management/version control: CVS, Subversion, Git/Mercurial/Bazaar, Perforce, etc. Good use of SCM is essential for professional software development.
Issue tracking: Bugzilla, Trac, FogBugz, etc. I would also consider an issue tracking system to be a critical piece of software.
Documentation: Like it or not, it becomes very handy to know your way around Microsoft Word. Knowing how to manipulate styles, headings, numberings, cross-references, etc. can make your life a lot easier when writing documentation.
You'd probably want to have a look at Silverlight. It's a Microsoft alternative to Flash and uses C#. WPF are also something to look at for interfacing.
It might also be worthwhile looking at MOSS.
I've always liked the Xceed controls. In a lot of cases you could always build your own controls. The biggest advantage to using some of these packages is that it saves you the time and they have also been well tested (if not by the company then by the people that are using them).
I've used a couple of different packages over the years and found that if you can use one it's not that hard to use another. The biggest thing is knowing what is available out there so you don't spend two weeks building something that you could have just paid a few hundred dollars for.
You should know about resharper (helper for VS)
Crystal reports - for reports,
Some Grid tools (google it, there are many - I wouldn't bother to learn until need one)
and study advanced topics like: WCF, WPF
Cruise control or other building tool, bugnet or trac - bug management tools...
And of course - AQtime or other Profiling tools.
.NET Reflector
Hawkeye - The .Net Runtime Object Editor
Infragistics
I'd throw mono in there as well. Since you're looking to give yourself an advantage over other developers and improve your value to companies - having cross platform experience is advantageous as well.
There are a lot of 3rd party controls that will help you achieve more in less time. But I don't think many of them will really improve your coding skills (calling someone else to do all the work doesn't teach you much about how to actually do thise things yourself, but familiarity with them and the ability to learn new libraries is a good skill to practice)
Resharper is good for improving your coding skills (code analysis), coding style (autoformatting), and it's a great refactoring tool. It's expensive, though.
Microsoft do some free code analysis tools for Visual Studio (FXCop for code analysis, and there is also a Static Analysis addin) which will help improve your code quality.
AtomineerUtils (my own addin) encourages excellence in documentation and generally improves your code quality (by encouraging good naming style, etc)
Focus more on the tools used in the software development process. Enterprise Architect is used for designing applications from a high level. Once you design you application's business classes you can generate your classes' skeletons. You will be responsible for you code implementation once the class structure has been created.
For implementation purposes look at several C# platforms mentioned earlier. You want to focus Microsoft's WPF, WCF, WF. WPF is ok but it can not be used prior to .net 3.0 so check your client's requirements. I'm working on a project that targets the .net 2.0 because of restrictions by the client so the applicaiton was designed in WinForms. Silverlight is an option as well.
In addition, read up on design patterns as this will help you avoid creating high maintenance applications. A good book is Design Patterns in C#.
For testing look at the Visual Studio TFS system or third party programs like NUnit. You can google NUnit. This will help you ensure that your code does what you intended it to do on a granular scale.
Also, take a look at some of the source control software avaialbel like Subversion, Rational ClearCase, Visual SourceSafe. For large projects with multiple developers you'll need a source control tool that has multiple branches so that each developer has his or her own sandbox within the source control system.
I'm a big proponent of ComponentOne and use it in my new applications regularly. I find that if you're proficient in .NET winforms in general, C1 are very easy to pick up on and usually do what you want with little effort.
A couple people mentioned Telerik. I demoed it fairly extensively and found them to be a bit more complicated because they contain a ton of configuration options for look and feel. Awesome if you're some sort of graphic designer, but unless you're building the next Windows Media Player, I think it's overkill. The learning curve for the theming seemed a bit much for what I was trying to accomplish.
C1 and Telerik both run about $1000 to $1300 depending on what license you get.
You should also check out the Krypton toolkit. It free and has a lot of nice controls.
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...