Adding Log4Net to your MVC project

Log4Net supports writing to multiple sources through the use of “Appenders”. For this post, we will take a look at the AdoNetAppender which allows us to easily write logs to a database table. To begin lets create a new MVC project.

Next we add a reference to Log4Net using the NuGet package manager.

To continue, add a new XML file to your solution, name it Log4Net.config and then copy the following code into the new file. The AdoNetAppender can get tricky because it has a few options that usually go undiscussed. The first tricky part to note here is the “bufferSize” attribute which when set to 0 indicates not to use buffering. Once we complete the Log4Net configuration we will see that logging data to the table is very easy and that it will not be extraordinary to log more than 10 messages for each page request depending on the amount of work a page processes.  To mitigate the impact increased database traffic would have on performance the AdoNetAppender allows us to batch these inserts into the log table. However, I recommend leaving this setting at 0 until you notice a performance impact. I consider this the first hiccup for installing Log4Net as some examples I have seen set this value to 10 and then skip discussing this piece. This usually makes it look like logging is not working when we run a simple logging test with one example message because only after we have 10 messages will the entire buffer be flushed and written to the database. Another core feature of Log4Net is the ability to configure your log level. Log4Net captures information in prioritized categories.

  • Fatal
  • Error
  • Warn
  • Info
  • Debug

In our example we have configured the Appender to capture information at the INFO level. Unless we change this setting our messages created under the DEBUG category will not get saved to the database. However, we will still see the more severe categories of FATAL, ERROR, and WARN in addition to INFO. By using this priority of severity I find most projects do not need the buffering option and are instead deployed with a WARN or ERROR level setting while the DEBUG and INFO settings are reserved for developer workstations and QA servers not being load tested. Another hiccup I usually see is found in the insert statement itself. Make sure your insert command matches the log table you created. For our example we will use the following SQL to create a log table.

CREATE TABLE [dbo].[Log4Net] (
[ID] [int] IDENTITY (1, 1) NOT NULL , [Date] [datetime] NOT NULL , [Thread] [varchar] (255) NOT NULL , [Level] [varchar] (10) NOT NULL , [Logger] [varchar] (1000) NOT NULL , [Message] [varchar] (4000) NOT NULL , [Exception] [varchar] (4000) NOT NULL

The last piece to discuss is the connection string which I intentionally left as “{auto}” in our example. By default this configuration file is not loaded by the application and as such our logging is not yet enabled. Also, in most scenarios, we want to use the same database connection string throughout the application. To accomplish both of these goals I created the following helper class After copying this class into your project simply call the public method “InitializeLog4Net” during the “Application_Start” event of your Global.asax.cs class. The Log4NetManager class will load our Log4Net.config file and the Appender configuration it contains. Next it will find the AdoNetAppender settings we just loaded and override the connection string (if it is set to “{auto}”) with the connection string specified for our entity model which takes care of keeping our two connection strings synchronized! At this point, Log4Net is configured and ready to run. All we have to do now is create some log entries.

To create our log entries we need an instance of a logger. The typical usage scenario is to get a logger that represents the class you are working in, as we do here using the typeof operator. After that we can create error messages by category. In this example “logger.Debug” will be ignored by the logger because we set the log level to INFO. In the second example we insert our test message “HELLO WORLD” and then finally we catch and report an exception message that occurred from an InvalidOperationException. Now, each time the Home/Index action runs it will insert two new records into the Log4Net table in the Northwind database as configured by the our entity connection string. via:

Earn Your Microsoft Certified Specialist: Server Virtualization Title with a Free Exam

Are you responsible for designing, implementing, and managing a virtualization infrastructure? Looking for a way to validates your skills on current virtualization technologies? Wondering how you can improve the trajectory of your career? Now is your chance to do just that, with free online training and an exam voucher from Microsoft!

What you get: The title of Microsoft Certified Specialist: Server Virtualization with Windows Server Hyper-V and System Center

How you will get it:

Still thinking about it? Here’s Chris Harney, president and founder of The Virtualization Technology Users Group, discussing why people need to be able to speak more than one virtualization language, and why it’s good for your career.

*The fine print: The number of free exams is limited, so be sure to schedule your appointment to lock-in your free exam. Vouchers expire and all exams must be taken by June 30, 2014.


Subversion Best Practices: Repository Structure

Maintaining a Subversion repository can become a complex task, and implementing the right project layout from the very beginning is crucial. As Subversion doesn’t impose a strict file structure, users are free to tailor Subversion repositories to their project’s needs. Users can organize Subversion on a ‘one project per repository’ basis or create multiple projects within the same repository; and have considerable freedom when it comes to how they use Subversion’s trunk and branches. In this post, we’ll look at some guidelines and best practices on how to keep Subversion files, for users who are embarking on a new project in Subversion.

Multiple Projects: Single Repository vs. Multiple Repositories

In modern software development, it’s normal for teams to be working on multiple projects simultaneously. If this sounds like your organization, the first question you’ll need to answer is: should I set up a single repository for multiple projects, or create one repository per project? Although the experience will be slightly different for each project, there are some general benefits and drawbacks to each approach.

Single Repository

Single repositories are typically suited to organizations managing multiple, small projects that require cross references, cross tracking, etc.


    • there is a single location where all the code is stored, even for projects you aren’t directly involved in.
    • ability to reuse common libraries.
    • lack of duplicated maintenance (e.g only one repository needs to be backed up.)
    • the ability to move data between projects more easily, and without losing any versioning information.
    • all projects share the same repository history.
    • typically less administration – new projects can be created without creating a new repository, and without the help of sysadmin.
    • you can delete entire projects without losing the record from Subversion.




    • Subversion uses repository-global revision numbers which apply to entire trees, not to individual files. The revision number for projects will increase in accordance with the rest of the repository, even if no changes have been made to that particular project.
    • unable to use unified logging (svn log command).
    • branching can be complex when many folders and files are involved.
    • dumping/loading one huge repository can be time-consuming.



Multiple repositories

These are typically suited to multiple large unrelated projects.


    • the ability to define different access permissions, for different users.
    • each project repository will have its own revision sequence.
    • the version number is meaningful for all projects.
    • projects have a tendency to increase in size, and numerous large projects on a single repository can become difficult to maintain. It is typically easier to manage large projects with a ‘one repository per project’ approach.
    • can tailor each repository’s structure to suit a project’s unique needs. This can include branching, tagging, naming conventions, etc.




    • Subversion does not support merging code between projects in different repositories, and the transplanted code will appear in the new repository with no history. This also means you cannot perform merges if you need to temporarily maintain two versions of related code.
    • different projects have different mailing lists, which can be a problem if there’s cross-over between two related, but separate, projects.



There is also the potential to have more than one repository, and to group related projects within the same repository. This allows related projects to share data, and when new revisions are added to a repository, they are more likely to be relevant to everyone who uses the repository.

Project Layout

Once you’ve decided whether to organize your projects in a single or multiple repository structure, it’s time to plan your project layout. Putting some thought into your layout in the beginning, can help you avoid having to move files around later.

An illustration of how a Subversion Repository evolves using branching, tagging and a code trunk.

Here are some best practices for getting the most out of your project layout:

    • Project root – This is the anchoring point for a project. A repository may contain one project root, or multiple roots, but each project root contains three subdirectories: /trunk, /branches, and /tags. The use of a project root is officially recommended by the Apache Subversion project.
    • Trunk – This is where you should store current release code – only! Don’t muddy the trunk directory with revisions or release names.
    • Branches – Use these to work on significant changes, variations of code etc, without disrupting the current release code.
    • Bug fixing on a branch – Branches should be created to fix major bugs; this allows bug changes to be immediately worked on without disrupting whatever work is currently underway in the trunk/development branches.
    • “Toe in the water” branches – Branches can be used as a code “sandbox” where new technology can be tested without risking the working code. If things go right, the new code can always be merged back into the trunk.
    • Tags – Should be used as “code milestones” providing a snapshot of the code at specific points in its history.
    • Tagging bug fix / development branches – when creating a code or bug fix branch, it’s useful to create a “pre” tag, and a “post” tag after the bug fix or code change has been completed:

Ready to start a new project with Apache Subversion? Certified open source Apache Subversion binaries can be downloaded from the WANdisco website.