A Much Easier to Use ListView - CodeProject

A Much Easier to Use ListView - CodeProject:

'via Blog this'

Understanding and Implementing Facade Pattern in C# - CodeProject

Understanding and Implementing Facade Pattern in C# - CodeProject:

'via Blog this'

Configuring Database Mail in SQL Server - CodeProject

Configuring Database Mail in SQL Server - CodeProject: "tabase Mail in SQL Server"

'via Blog this'

Patch Installation error

I ran into a sticky situation while trying to apply a second patch to an application but failed, instead getting an error. The actual scenario was that my product was version 2.0 which was already patched with version 2.1, applying patch 2.2 failed but when patched directly with 2.2, it upgraded successfully.

This is the upgrade error I received while patching;

"The upgrade patch cannot be installed by the Windows Installer service because the program to be upgraded may be missing, or the upgrade patch may update a different version of the program. Verify that the program to be updated exists on your computer and that you have the correct upgrade patch."

Notice the error number is missing, that a fail to installshield.

Among other,s the reason why this error occurs is because the application to upgrade is either not installed, the Upgrade code has changed or the previous patch Package code may be similar to the new patch. In my case I discovered that the patch 2.1 was somehow changing the upgrade code making it impossible for the 2.2 patch to install.

My solution to this issue was to change the Transform Filter Settings on the previous packages page. I changed the ‘Match Upgrade Code’ setting to “NO” and left the “Match Product Code” setting as ‘YES’ this would make sure that the patch only upgrades the product version it is supposed to leaving out the upgrade code validation. This may be a crude method but it fixed my issue in the nick of time.

Here is an image to demonstrate.

How to fix error 1911- Could not register type library for file.

I landed into problems when a patch I had created failed during installation and gave the error “Error 1911. Could not register type library for file x. Contact your support personnel”. This was not the first time I have dealt with the same installation error but this time it was different because it occurred on a patch.

Here are some tip on how you can fix this problem:

This error is likely to occur if the installation package extracts the wrong COM information  i.e an old library version could be registered at build time. The fix  to this is to clean the build machine, this involves using Regclean or any other such tool to remove registry information which could be out-dated or from an older version. Replace the components, register them afresh and redo the build.

If cleaning the build doesn't work, The second approach would be to check if there are double entries in the Typelib table in direct editor. If there is more than one entry, delete the one with the wrong Lib ID. You could also remove the dll from the project, restart the project then re-add the dll again otherwise completely remove the library file if you do not need register the file.

When dealing with a patch, maybe you should try finding out if the developer had broken the components compatibility. Patching components with broken binary compatibility can be a real pain. If true, ask the developer to restore compatibility and recompile the components.

Custom exception in C#

When working with large projects with many integrating modules you will find developing custom exceptions imperative. In this post I will demonstrate how to create a simple custom exception.

The main motivation behind creating custom exceptions is that it improves code quality through simplified and improved error handling. Custom exception achieves improved error handling through separating application specific errors and other exception. When developing application modules you get to create object with specific responsibilities, at the same time you think around violations that would occur example invalid data or violation of logical constraints and throw relevant exceptions.

Here is an example of a custom exception for a login module.

Define a class and inherit the Exception class

using System; 
using System.Runtime.Serialization;

namespace LoginException 
{ 
    public sealed class LoginException : Exception 
    { 
        public LoginException() 
            : base() { } 
    
        public LoginException(string message) 
            : base(message) { } 
    
        public LoginException(string format, params object[] args) 
            : base(string.Format(format, args)) { } 
    
        public LoginExeption(string message, Exception innerException) 
            : base(message, innerException) { }

        public LoginException(string format, Exception innerException, params object[] args) 
            : base(string.Format(format, args), innerException) { }

        public LoginException(string message, Boolean LogError ,Exception innerException) 
            : base(message, innerException) { 
        
            if (LogError){ 
                LogMessage(innerException,message); 
            } 
        } 
        public LoginException(string format, Boolean LogError, Exception innerException, params object[] args) 
            : base(string.Format(format, args), innerException) {

            if (LogError){ 
                LogMessage(innerException, string.Format(format, args)); 
            } 
        }


        private void LogMessage(Exception ex,string message) 
        {

            try 
            { 
                if (!System.IO.Directory.Exists(Properties.Resource1.LogsPath)) 
                    System.IO.Directory.CreateDirectory(Properties.Resource1.LogsPath);

                //Open a file and save the error message.

                System.IO.StreamWriter file = new System.IO.StreamWriter( Properties.Resource1.LogsPath + "\\log " + DateTime.Now.ToString("ddMMyyHHmmss") + ".txt");

                file.WriteLine(message + Environment.NewLine + ex.StackTrace); 
                file.Close(); 
            } 
            catch 
            {

            } 
            finally { } 
        }

       }

} 

How do we implement the class after defining it:

1. You can use the custom exception with a try catch statements as done below.

try 
{ 
     //Code to execute here 
} 
catch (LoginException ex) 
{ 
     //do something

}

note better that this exception will only catch exception of type LoginException. You can improve on this to handle any other regular exception.

try{

    //Code to execute here

} 
catch (LoginException ex) 
{

    //do something

}

catch (Exception ex) 
{ 
    throw new LoginException(“error login in”,True,ex) 
}

Creating Good Log Messages

Sometimes a bug emerges at a customer site and the support staff sends me a log session and a set of recreation steps to figure out the bug. With rich log messages, that provide indication of what and where the application failed, am able to understand the bug and ultimately fix it. This has lead me to understand how important log messages are in an application.

There are tones of article emphasising on the importance of good programming practices etc but very little about logging practices. On this post am going to describe a good log message based on my experience.

To start with, a few rules that you should follow when logging;

1. Log messages should be short and precise.
2. Avoid spelling mistakes in the logs.
3. Provide fatality levels in your messages. This will help the support analyst to rate the bug/issues severity.
4. Avoid fancy characters in the log messages .
5. Avoid logging your messages to the database, this cost space and reduce performance.
6. Always have a consistent format for your logs. this helps is keeping uniformity

Here is how a good log message should appear:

ERROR|| DATETIME: 22-Aug-2012 13:24:24 || DESCRIPTION: Could not write to output file 'C:\thisfolder\myfile\report1.txt', 'The directory name is invalid.' || SOURCE: Report.SaveReport || PROCESSID: 3456 || PCNAME: Mark-laptop||  USER: Mark || BUILD VER: 2.1.1 || OS :  Windows 7 Version 6.1 Build 7600

 

LOG MESSAGE BREAK DOWN

You will realise I have used a double slash to segment my message, this is to make it readable. Lets break down the sample message and look at it bit by bit.

SERVERITY– This is the first section of the message indicating ERROR. It is very helpful in determining the importance of the message at a glance.

DATETIME: It is the date and time when the error occurred. This is important in case you would like to know the frequency of error or even tag it to a certain external process or event.

DESCRIPTION:  This is a test message of what happened. This can be the runtime  message generated by the debugger or a custom message by the developer.

SOURCE: The code location that generated this message. This will save you a lot of time figuring out where you need to look in your code. In my case I have used the class_name.method_name format.

PROCESSID: In case you have several processes it good to know which particular one is being a nuisance.

PCNAME: This gives you the machine where the error occurred. You could also provide the server name just incase your logs come from different hosts.

USER: An identifier of the user logged in, this is important if you want to track a users actions within the session. You could use a session id instead of a username like I have done.

BUILD VER: This is the code version running. This is very important as the location in the log may be for a different version of code from what is currently running.

OS: Some bugs are tagged to Operating Systems therefore it is important o know what platform the user was on.

 

Most of the time we rely on the debugger to fix our bugs but suppose a bug occurs in site and you manage to fix it through the information provided by the logs. This is the reason why we should always improve the content to provide as much information as possible.To do this think about what information the log provided, evaluate if was it was helpful and find out if more content be appended to make it even more helpful.

Making the log rich enough may not be your priority because  as the developer you have the debugger,  but it a very important aspect for the support team and the customers too. You will be shocked at how may issues the support team can resolve at site just because they can make out what the problem is. This makes it easier for you as a developer and you can concentrate on more relevant issue.

Those are my thought about log messages. If you may have anything to add please drop me a comment.