We Keep Coding

In which layer, should I do logging for MVC with many layers

I have a MVC project which has Model,DataAccess,Business and View layers. I am intending to use NLog to log exceptions into text files. I am not sure in which layer I should log errors, that is my first question. I read some blogs which recommend to log errors in View layer. I am not sure about that.

I think the best way is to use MVC. You should do logging in one place for common exceptions and the only common place you get is top-level, MVC in your case.
There are special error handlers for MVC that you should utilize/override to get the behavior that you want + global.asax generic error handler for stuff outside of MVC. That will cover exceptions happening in any layer compared to doing it in other places you would have to duplicate it.
As already mentioned in comments you can use Elmah as well. It will pretty much do what I have described, but automatically, you just add an Elmah.Mvc package and set it up to log to a file. You need to be careful not to expose elmah endpoint so that everyone can see your logs.

System.Net.GlobalLog - How do I view the output of this?

Many classes in the .NET framework (especially in the socket/network classes, which is what I'm looking at) use System.Net.GlobalLog (an internal class) to log trace messages somewhere. You can view example uses of things like GlobalLog.Assert and GlobalLog.Print in the SslState class:
SslStream source code
This is different from the System.Net.Logging (also internal) class, uses of which can also be found throughout the socket/network classes.
For System.Net.Logging, I know I can use a <system.diagnostics> configuration block in App.Config and that will result in System.Net.Logging messages getting logged if configured properly. However, this does not appear to influence System.Net.GlobalLog.
After searching around for about an hour, I cannot seem to find any information about locating the output of System.Net.GlobalLog. Does anyone know how to locate/view/control the output of this?

As you stated, GlobalLog is an internal class to the System.Net assembly. Without being able to modify the System.Net assembly you won't get access to that class.
That said, you might want to review the following: http://www.123aspx.com/rotor/RotorSrc.aspx?rot=42941
It looks like you have to have compiler flags TRAVE and DEBUG set in order to get it to work.. but I'm not seeing where it actually does anything with the logged information. The comments suggest that it is supposed to look for an environment variable setting and dump the log to a text file somewhere on the system; however the code at that page seems either incomplete or it simply wasn't finished.
My guess is that you need to find some other way of getting access to the logging info you want.

I don't have enough rep to put this as a comment on the existing answer but I wanted to figure out what was happening in the TcpClient and Socket classes but also found they couldn't be stepped into. The closest I got was by monitoring the Windows API calls that were being made. I used a freeware tool called API Monitor found here: http://www.rohitab.com/apimonitor.

Using log4net with asp.net web forms

I am trying to incorporate log4net into my web application. I have already done so with the newer portion based on .net mvc, but am having trouble incorporating it into the web forms based portion of my app. I have looked around for an example and have not come across one.
In order to narrow my question down, let's assume I know how to configure my web.config file. My questions are:
(1) I have considered placing the actual call to log4net in a "Global.asax" file as well as placing it in my base page (on which all other pages are built). Should I be placing the actual code in either of these places, and if not where should I put the code?
(2) My understanding of the code is that I need to instantiate a log, and then have that log log stuff when I want to it (the specifics of log being taken care of by web.config), but I don't know what that code should actually look like. So, what code should I actually be placing in my file? (example would be appreciated)
Thanks

just place the code where you need it.
to initiate i just use this line in every page i need it...
static Logger log = LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType);
so the logger gets the name of the current class including full namespace.
i also use the logger in global.asax for example error logging
protected void Application_Error(object sender, EventArgs e)
{
StringBuilder sb = new StringBuilder();
sb.Append("Unhandled error occured in application. Sender: ");
sb.AppendLine(Request.RawUrl);
sb.Append("Query: ");
sb.AppendLine(Request.QueryString.ToString());
Exception ex = Server.GetLastError().GetBaseException();
log.Error(sb.ToString(), ex);
Server.ClearError();
Response.Redirect("~/Error.aspx");
}
but i seperate the log config from the web.config. it's easier for me and you don't have to handle so big files. i also think that the application is not restartet, when you change the log config file. if you update the web.config the application is always restartet as far as i know.
to accomplish this you just need to add following to the web.config
in add
<section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net"/>
than add this line somewhere in the web.config
<log4net configSource="log.config"/>
and then the file "log.config" has all the listeners configured. but don't forget to copy the file to your production/test environment. otherwise you may get strange error messages.
hth

Placing it in the base page sounds like a good idea, then when instantiating using GetLogger you can pass in the page you're logging for (being as specific as possible about where your log calls are coming from really helps debugging). You'll also need a call to .Configure after instantiating which is what always catches me out (need to import Log4Net.Configure for this)
Place your listener config in web.config and define min/max levels via LevelRangeFilter (DEBUG is lowest, FATAL is highest).
Usage is pretty simple - you just log with the required level, EG: log.Info, log.InfoFormat, log.Error, log.ErrorFormat (the formats just work like String.Format) - anything below the minimum configured logging level will be ignored so you can put as much logging in as you like.
Have you also checked out Elmah? This allows you to track unhandled exceptions. http://code.google.com/p/elmah/

Let me share with my experience of using logger. Usually I use it with IOC container, i.e. Windsor.
So initialization of logger I make in Global.asax file, as it is runned once per app, and berore all requests. This is proper place to initialize logger.
As for the place where you should call the log, there isn't any recommendation. You should call where you need.
If you are logging some events based on page lifecycle, of course you should use logger in page code behind file. But if you want to trace your components, better extract logics in separate library and use logger within it.

Error logging sample project

I need to create a Error logging project from scratch in C#.
I would like to save to a file with several levels, this logging project I am taking as an assignment from which I can learn many things and want to build it as small loggin utility for now.
I saw few loggin project which has singleton pattern and a config file having some entries and also in the consuming application config - some references of logger proj interface are there
can some one please give me an idea as how can I create a new logger
proj from scratch and what is the purpose of having entries in
config ?
pseudo code for logger project or any link
Thanks in advance.

Instead of implementing your own logging mechanism you may want to check whether existing components are an option. For example log4net is a frequently used framework that people use for .NET based projects.

Also, the Logging Application Block from Microsoft:
http://msdn.microsoft.com/en-us/library/ff632023.aspx
http://msdn.microsoft.com/en-us/library/ff664569(v=PandP.50).aspx

There are several key elements you need to consider before making one from scratch. Just to name what comes to my head :
How do you want to log? Do you want to save logs to a file, in a database, to send mails, just to have the logs shown in a console?
If you persist the logs, do you want to log everything, forever, or you want a "rolling" X lines to be kept, the rest discarded?
Do you want to have several level of logs? For example, you could log some things Info, Warning, Error, Critical Error, etc.
Do you want your logging library to support custom formatting for the logs?
As for the question about the config, it's really something you want to do. If you're talking about the app.config files, it allows you to can change the configuration of your application without rebuilding it. It can also provide some default parameters the user can override. By user, I mean another developer using your library.

Create custom logger, should I extend class from log4net

I am doing something unusual.
I have an application, it runs as a windows service.
what it does is that, it monitor one folder, when ever there is some new file put into that folder, the application will do something to the file.
Whenever there is an error when processing one file. I need to create a text file, and put the error/exception information into that text file. (later i can do something with this file)
so there is something like this
FileWatch, when there is a new file, do following :
try
{
processing file
}
catch(Exception ex)
{
MyLogger write exception message into one new text file
}
So far how i did it is that. I create a class for example MyLogger, whenever i new one MyLogger, it creates a text file (the name matters, need to be a specific format), and there is one method in side MyLogger "WriteError(string message)", it writes text into that file.
Since i used log4net in my application. Do you think i should modify my logger, to extend some class from log4net, so that i can get some benefit? (not sure what kind of benefit i will get, but log4net is a good logging framework, the way it handle text file might have thing that i do not aware)
Thanks

log4net or any other generic logger is helpful if
1) you want to have a consistent logging facility in many places across your application; and/or
2) you want the ability to customize logging format, level and so on.
From your description it sounds like there is a single point in your app where you need to log the exception in a specific way. If this is correct, you will probably gain no benefit from creating a custom logger - just write a method that logs exception to a file in the way you need.
If I misunderstood you, and there is a need for generic logger (that is, either 1) or 2) above is true), extending log4net by inheriting a logger or creating a wrapper is fine.

I've created log4net wrappers before. I find it handy to start this way as you don't always know what the logging requirements are at the start of a project. My rule has been that the log4net library can only be referenced from my own "logging" namespace. This way, the application code only calls the wrapper, and the wrapper is the only point of contact to the log4net functionality.
In the long run, it's probably worth investing in building your own logger. If you encapsulate log4net properly, you should be able to make this upgrade rather easily, without having to change your code.

Why not use Trace Listeners from the .NET framework? They provide many of the benefits of a logging network, without the need to incorporate an external framework.
Benefits include centralized log management and the ability to direct the output logs to one or more sources such as a console window, text file, or the Windows Event Log.

You should spend some time creating your own logger that does exactly what you want. This would be the best way. Is also fairly easy and you have full control on the customization so you can make the output look and feel as in log4net. You could Google for logging sample and start modifying that one.

I am not sure if I would use a log framework for this purpose. I have the impression that writing this text file in the exception case is part of your business process. Logging serves a different purpose that can be turned off without affecting business processes...