I teach introduction and advanced .NET development courses for a local community college and one item that I always cover in each class is a discussion around Memory Management and Garbage Collection. I am often asked by my students if this is something that they really should be concerned about and my opinion has always been yes, but I know that many developers feel that having an intimate understanding of how Garbage Collection is completed is unnecessary. Finally after a number of constant reminders from students, I thought I would actually put out my "simple" version and explanation out here that I give my students each semester and gather some feedback from my blog readers on their thoughts on the manner.

Now first of all, before I get into the true content of this blog posting I do NOT want to start another round of the religious war that always seems to happen when you start talking about the usage of Visual Basic or C#.  The purpose of this blog posting is to put a little perspective into why I choose to work with a specific language for different projects, and the evaluation criteria that I use when making the choice for individual projects.  Yes, I'm a C# MVP, C# is my preferred .NET language, but I'll be the first to admit that there are times and places where VB is a necessary language.  In this article, I'll start out by providing a bit of background as to WHY I'm blogging about this, the evaluation criteria that I use when looking at a project and some other general information that I've found over the years.  Keep in mind the disclaimer found at the bottom of this posting, these are my thoughts, and mine alone, if you don't like them, which I'm sure many of you will not that is fine, but I wanted to put a bit of perspective on my take for the common argument.

One of the most common questions that I have been getting recently has been "what source control provider do you use and why?".  This article is the first in a series of two articles about source control.  This article takes a quick look at criteria that I believe is important to consider when it comes to evaluating source control systems for use.  The next article in the series will be a review of the source control system that I use, in relation to the evaluation criteria that I list in this article.

While working through some issues recently with some legacy code written by someone else I was faced with a horrible case of a shared object that was writing to the file.  This was a "custom" logging implementation and opened a file for append, inserted the line, and then closed the file.  Well in times of heavy load the system would encounter errors such as "Cannot access ___ because it is being used by another process".  So in effect the file was either still open, or the lock was not yet released.  This post goes through a bit of the detail on how I resolved the issue.

A question I have been asked many times recently is how do you debug a DotNetNuke module that has been developed using the WAP (Web Application Project) development model.  This is a question that I have known the general answer to for quite some time, but I have never actually had a need to truly debug one of my custom modules.  During the course of helping a client with an issue today I actually took the time to document all steps necessary to debug a WAP DotNetNuke Module within Visual Studio 2005.  This article will walk you through all steps necessary to debug your project.