Hash matching in .net and SQL

I was faced with a problem where passwords were being stored in sql as a hash, and each time a new password was needed, I had to write code to generate a new password --FAIL!

Anyway, I decided to sort this out.

 MSSql offers the Hashbytes function to create a hashed byte array from a string, as follows:

SELECT HashBytes('MD5', 'teststringtohash')

That was easy! Now, since the passwords are being stored as a string, all you have to do to convert it is the following:

SELECT CONVERT(NVARCHAR(32),HashBytes('MD5', 'teststringtohash'),2)

Which returns '5B076E2B8572A2A80645BFD1D4046D23'.

Now, to generate the same hash in c# so we can compare to the database, all you have to do is use the HashAlgorithym class, compute the hash and convert it to a hexstring. Since we are using a MD5 hash in SQL, the HashAlgorything will also have to be a MD5 hash. See code below:

1) Create the hash algorithym.

HashAlgorithm alg = MD5.Create(); 

2)Compute the hash, and use the BitConverter.ToString to get the hex string. The hex string contains '-' between each byte, so remove them to match sql! 

byte[] hashedData = alg.ComputeHash(Encoding.UTF8.GetBytes("teststringtohash"));            
string password = BitConverter.ToString(hashedData);
password = password.Replace("-", ""); 

All you have to do from here is make sure that password == sqlpassword :)

Dependancy Injection / Inversion of Control (IOC) in .net c#

Introduction

DI is one of the most  things that is assumed to be difficult, and without understanding it can be one of those things which you will never try again if you get it wrong. I myself was one of those people. 

I have been working with a colleague who insists on using it, and being open minded to the suggestion again, I asked him to show me what its about  - in a correct implementation. He also gave me a fantastic book to read by Mark Seemann called Dependency Injection in .net.

I am now a fan of DI, and can see the use for it. This article explains DI, and how to do it practically, along with the reasoning behind it.

What is Dependency Injection

DI by definition is "a set of software design principles and patterns that enable us to develop loosely coupled code" 

Within OOP, this means that collaborating classes should rely on the infrastructure to supply the necessary services. This leads to code that is more maintainable and easier to test.

What is Loose Coupling and how does it fit with DI?

Loose coupling in a design pattern is "Programming to an interface, and an implementation". Following this design pattern makes your code more extensible and therefore leads to higher maintainability. 

DI is a technique that enables Loose Coupling in your code.

DI and Loose Coupling in the real world

The best "real world" analogy I have come across when it comes to explaining Loose Coupling is the  plug and socket.

For anyone that has gone to a hospital, they would most likely seen something like this:

TV wired directly to the wall

As you can see, the TV is wired directly to the wall. Normally it would make no practical sense to have your electrical device wired directly to the wall outlet. If your device broke, you would need an skilled electrician to come and disconnect the device from the wall, and replace it for you. This would come at a practical cost.

What would make more sense is to have a plug an socket, where any old handy man can come in, unplug it, and swap it out - meaning no electrician required :

Simple Plug and socket

This kind of analogy can apply to our programming. The socket in this case is an Interface defining what shape the plug needs to be. Not only does this make it more maintainable, it means we are no longer constrained to one type of device. We could easily swap it out for a new version HD 3D tv, or even a projector of some sorts.

To give a real life example as to how to implement this within your application, think about caching.

Scenario


You are developing a web application which only sits on one server. You know that within one year, the site will grow to be on a web farm and some of the caching needs to distributed evenly. For now you don't have the time to develop and test that the caching works, so you are just going to stick to the "Session" cache.

You want to be able to swap this caching mechanism out in the next release to be a distributed caching system, such as SQL or Appfabirc, NCache etc.

Solution


Below is an example of how we would structure the application so it has a loosely coupled caching mechanism:

1) Create an interface that has the Add and Get from cache functionality:

 public interface ICacheProvider
 {
        void AddToCache<TValue>(string key, TValue value);
        TValue GetFromCache<TValue>(string key);
 }

As you can see, we have a generic "AddToCache" which takes a key and object. We also have the "GetFromCache" which takes a key and returns a generic type.

2) Create an implementation of the ICacheProvider. In this case it will be something that adds to the Session Cache, so we will call it SessionCacheProvider:

    public class SessionCacheProvider : ICacheProvider
    {
 
        public void AddToCache<TValue>(string key, TValue value)
        {
            Session[key] = value;
        }
 
        public TValue GetFromCache<TValue>(string key)
        {
            return (TValue)Session[key];
        }
    }

3) In your code behind, implement the ICacheProvider

public class SomeCodeBehindFile
    {
        ICacheProvider cacheProvider;
 
        public SomeCodeBehindFile(ICacheProvider cacheProvider)
        {
            this.cacheProvider = cacheProvider;
        }
 
        public void AddItemToCache(string itemClicked)
        {
            this.cacheProvider.AddToCache<string>("SomeItemKey", itemClicked);
        }
 
        public string RetrieveItemFromCache()
        {
            return this.cacheProvider.GetFromCache<string>("SomeItemKey");
        }        
    }

 As you can see, the SomeCodeBehindFile class is completely unaware of where the cache is, or what its doing with this cache. All it knows is that is can add to some cache, and get data from some cache.

What ever creates an instance of this class can also pass in any cache provider they want. In this case, we would pass through an instance of the session cache provider: i.e.

SomeCodeBehindFile scbf = new SomeCodeBehindFile(new SessionCacheProvider());

This method of setting the implementing class is called Constructor Injection. There are different techniques as to how to set the implementation class. We will cover the different ways later. For now, just know that we can easily switch the implementation to be a AppfabricCacheProvider without having to make any code changes in the SomeCodeBehindFile class - this makes it highly maintainable!

The mis-conceptions of DI


There are 4 common misconceptions about DI, which I myself fell prey to. Below are the actual facts on DI


DI IS NOT only relevant for late binding. 


Late binding refers to the ability to replace parts of an application at runtime. Late binding is only one of the aspects of DI

DI IS NOT only relevant for unit testing - if anything it promotes it - if you so choose to do it (which you should)
DI IS NOT an abstract factory


This is one of the biggest myths I had to unlearn. DI itself is not a  dependency  factory. 

It doesn't resolve dependency objects for you. It is not a Service Locator - DI is in fact the exact opposite.

DI is a way to structure code, so that the developers never imperatively ask for the dependencies, but in fact force consumers to supply them.



DI DOES NOT require a DI container.


The DI container is an optional library the can make life easier when assigning components on the application wire-up. Its is by no means a required library. Latter on we can look at the differences between using a container and doing it manually.

...TO BE CONTINUED

Sql Connection Pooling in .Net

Sql Connection pooling is one of the hidden heros that not many developers I know will take time to look into.

Granted, ADO.NET covers up so much of whats really going on, and takes care of of the nitty gritty details, so as a .net developer, you should have to worry too much -> WRONG! When it comes to optimizing performance, you NEED to know whats really happening!

Sql Connection Pool Basics: 

Fact: Opening a database connection is a resource intensive and is a time consuming operation.

A connection pool is a way to cache sql connections that are maintained so that the connections can be reused when future requests to connect to a database is needed. By reusing active database connections,  the performance of .Net applications, be it Web or Windows,  is increased!

Connection Pools in .Net are managed and maintained by the Connection Pool Manager.  When a new connection request come in, the Connection Pool Manager will check if the current connection pool contains any unused connections. If there are connections available it will return it, otherwise if all connections currently in the pool are busy and the maximum pool size has not been reached, a new connection is created and added to the pool. When the pool reaches its maximum size, all new requests are queued until a connection in the pool becomes available or the connection attempt times out.

Controlling the connection pooling behavior can be done via the use of connection string parameters. Below are the most common parameters that control most of the connection pooling behavior:

• Connect Timeout - controls the wait period in seconds when a new connection is requested (As mentioned above), if this timeout expires, an exception will be thrown. The default connection timout is 15 seconds.
• Max Pool Size - specifies the maximum size of your connection pool. By default it is 100 connections. 
• Min Pool Size - specifies the initial number of connections that will be added to the pool upon its creation. By default, this value is 0.
• Pooling - controls whether or not to use connection pooling. The default value is true.

Most Common Issues and Resolutions

The following exception is most probably the most common issue:
"Exception: System.InvalidOperationException
Message: Timeout expired.  The timeout period elapsed prior to obtaining a connection from the pool.  This may have occurred because all pooled connections were in use and max pool size was reached.
Source: System.Data  

at  System.Data.SqlClient.SqlConnectionPoolManager.GetPooledConnection(SqlConnectionString options, Boolean& isInTransaction)
   at System.Data.SqlClient.SqlConnection.Open()"

This exception usually happens due to Connections Leaks - a condition where your application does not close its database connections correctly and consistently.

When you "leak" connections, they remain open until the garbage collector (GC) closes them for you by calling the Dispose method on your SqlConnection object. Unlike the old ADO, ADO.NET requires you to manually close your database connections as soon as you're done with them. As we cannont rely on the GC to do the work for us, as GC can take a very long time to collect, we have to do this in code. There are 3 ways to achieve this:

Using the Close() method:

SqlConnection conn = new SqlConnection(myConnectionString);

conn.Open();

//execute query

conn.Close();

Using a "Try...Finally" clause:

SqlConnection conn = new SqlConnection(myConnectionString);

try

{

   conn.Open();

   //execute query

}

finally

{

   conn.Close();

}

and using the "using()" statement:

using (SqlConnection conn = new SqlConnection(myConnectionString))

{

conn.Open();

//execute query

}

If you use SqlDataReader, OleDbDataReader, etc., close them. Even though closing the connection itself seems to do the trick, put in the extra effort to close your data reader objects explicitly when you use them!

For more information, you can read:

http://betav.com/blog/billva/2007/05/managing_and_monitoring_net_co.html