How to trap Nlog events within your application

Being able to trap nLog log events within your application allows you to provide a default msg to your users without having to have the UI code everywhere in your application. 

This post describes how to setup nLog with an additional target that will fire an event in your application that you can then capture.

First there are a few changes to the log file;

Notice that we added a new target and rule for that target.  Next we need to add a class with a shared method to capture the event;

This allows you to catch the log event.

Busy

I have not posted very much the last few days because I have been working on several priority projects.

Media Repository System, Major update to our Jail Management System, upgraded to VS2010, upgrade our source control system, build an export system for our JMS, started a service controller application to handle difference process snap-ins, a face finding assembly to control pan-tilt-zoom cameras for taking booking photos, updates to our mobile system, deployed our mobile system to a customer, deployed our JMS to two customers, over seeing a Fire House Export module from our CAD system, generated several reporting services reports, and starting back on our new Records Management System.  And that was just the last week!

The good news is that I am starting to use VS2010 and the .Net 4 framework for server side applications and have had not issues running side-by-side with VS2008!

GhostDOC

Simplify your XML Comments!

GhostDoc is a free Visual Studio extension that automatically generates XML documentation comments for methods and properties based on their type, parameters, name, and other contextual information.

When generating documentation for class derived from a base class or for interface implementation (e.g. .NET Framework or your custom framework), GhostDoc will use the documentation that Microsoft or the framework vendor has already written for the base class or interface.

It supports VS2005, VS2008 and VS2010!

http://submain.com/products/ghostdoc.aspx

VS2010 Migration

Migrating to a new development IDE brings a number of issues when developing line of business applications.  With all the exciting features in VS2010 we still have to consider issues like third party component issues, Net Framework 4 availability on client machines, mixing of development IDE’s (VS2008, VS2010) and many other minor issues.

Im my migration from VS2008 and Source Gear Fortress source control to VS2010 and team foundation 2010 I am making baby steps.  First, I completed a long over due update to my Fortress source control (server and client) that addressed many existing bugs and brought VS2010 support.  Second, I have decided to start using VS2010 for new server based applications where Framework 4 deployment is not as much of an issue. Third, I have delayed adopting team foundation server 2010 until the IDE migration is completed.  This will allow me and my team time to get use to the IDE and test team foundation server.

Over the next few days I will be working on a few production projects using VS2010 targeting both 3.5SP1 and 4 frameworks using Fortress source control to test the waters.  I am also getting use to team foundation server 2010 by running sample applications in VS2010 and using TFS for source control.  This provides a nice test environment that allows me to get use to both VS2010 and TFS without compromising my production environment. 

VS2010 Side-by-Side Installation

Today I installed VS2010 Ultimate side-by-side with VS2008 on my primary development workstation. After sweating it out for about 20 minutes the installation went exterammly smooth. I have worked on several VS2009 solutions and a couple VS2010 test solutions without any issues.

Source Control Issue
I am currently using Source Gear Fortress (version 1.1.1) and debating upgrading to version 2.0.3 which will be a pay upgrade to obtain VS2010 support or moving to Team Foundation Server. I have a heavy investment in Source Gear with a couple repositories and a lot of projects. With the number of members on my team and current workload I don't want to take on the learning curve of a new ALM solution, however, at the same time I don't want to spend a lot of money on an upgrade I might not keep very long as I want to migrate to TFS as soon as I can.
If anyone has any thoughts on Source Gear Fortress 2.0 vs. Team Foundation Server on a team of less than twenty please drop me a note. Also, any thoughts on automating the migrations from source gear to TFS.