Log4net .NET Logging

Log4net makes logging in .NET easy. For myself I can say that using logging makes me a far more effective developer. Plus you can turn up interesting stuff :P

3 steps to get log4net

1.) Add the log4net.dll assembly to your project
2.) Modify a *.config file to include an appender
3.) Add code to load the config

1.) Is self explanatory



2.)

<?xml version="1.0"?><configuration>
<configSections> <section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler,Log4net"/>
</configSections>
<appSettings> <add key="log4net.Internal.Debug" value="true" /> </appSettings>
<log4net>
<root>
<level value="DEBUG" />
<appender-ref ref="LogFileAppender" /> <appender-ref ref="ConsoleAppender" />
</root>
<appender name="LogFileAppender" type="log4net.Appender.RollingFileAppender" >
<param name="File" value="logs/log2.txt" />
<param name="AppendToFile" value="true" />
<rollingStyle value="Size" />
<maxSizeRollBackups value="10" />
<maximumFileSize value="10MB" />
<staticLogFileName value="true" />
<layout type="log4net.Layout.PatternLayout">
<conversionPattern value="%date [%thread] %-5level %logger [%property{NDC}] - %message%newline" />
</layout>
</appender>
</log4net>
</configuration>

3.) In assembly.info add
[assembly: log4net.Config.XmlConfigurator(Watch = true)]
or
Log4net.Config.XmlConfigurator.Configure()

SQL Cursor Example

I am rarely required to do anything very difficult in SQL, and really SQL doesn’t get THAT difficult so this is maybe the second time I have used a cursor. What follows is a very basic SQL cursor example that I used earlier today. If it mattered more and I had more time I probably would have taken a look at doing this without using a cursor as cursors are non-performant. None-the-less it was a fun exercise. Another fine example,including the non-cursor implementation, can be seen here http://www.sql-server-performance.com/articles/per/operations_no_cursors_p1.aspx

DECLARE @customerId int,

@firstName nvarchar(255)

DECLARE Customer CURSOR FOR

SELECT customerId,

firstName,

FROM CustomerTable

OPEN Customer

FETCH Customer INTO @customerId,

@firstName

WHILE @@Fetch_Status = 0

BEGIN

-- row by row operations

Print

FETCH Customer INTO @customerId,

@firstName,

@vchCustomerName

END

CLOSE Customer

DEALLOCATE Customer

Go

Why We Use Properties in .NET

Properties are extremely useful in .NET for debugging, validation, raising an event when data is changed and changing data in other fields.

Let's look at an example.


public class Email
{
private string emailAddress;

public string EmailAddress
{
get
{
return emailAddress;
}
set
{
if (isValidEmail(value))
{
emailAddress = value;
}
}
}

public bool isValidEmail(string inputEmail)
{
string strRegex = @"^([a-zA-Z0-9_\-\.]+)@((\[[0-9]{1,3}" +
@"\.[0-9]{1,3}\.[0-9]{1,3}\.)|(([a-zA-Z0-9\-]+\" +
@".)+))([a-zA-Z]{2,4}|[0-9]{1,3})(\]?)$";
Regex re = new Regex(strRegex);
if (re.IsMatch(inputEmail))
return (true);
else
{
return (false);
//and possibly log error
}
}
}

In this example we have a private field named emailAddress and a Property named EmailAddress. This is useful we want to validate the email address before setting it. We simply test the value using isValidEmail() in the property setter. This allows us to omit this code from our procedural code(where we don't want to see it anyway) .

The Downside is that it does create some overhead and it is more typing. Hardly a sacrifice in todays world.

Properties are quite simply a more robust and future proof way to handle data. It is not necessary to use properties by any means but if there is any question as to the validity of data being passed in or if it is likely that the library will evolve then it is a good idea to use properties.