How to create a random (or unique) string (or number)

Problem

1. using an a primary key in a table
2. for security purposes like creating a salt to attach to a hash value

Possible solutions

1. Create a new GUID (Globally Unique Identifier) by using the GUID.NewGuid method
2. Use the RNG Crypto service provider to create a random byte array and convert it into a string
3. Use DateTime.Now if that would suffice

Example for using RNG Crypto Service Provider:

	byte[] saltInBytes = new byte[8];
	RNGCryptoServiceProvider saltGenerator = new RNGCryptoServiceProvider();
	saltGenerator.GetBytes(saltInBytes);
	string saltAsString = Convert.ToBase64String(saltInBytes); 

								

References

http://macronimous.com/resources/Secure_Password_Programming.asp

Find out the number of times a character is repeated in a string without using iteration

Problem

You want to find out the number of times a specific character is repeated in a string, but you don't want to use iterative blocks like while, for etc..

Solution

Use the Split method, and subtract 1 from the length of the string returned.

Example

	string input = "123#345#456#";
	int count = input.Split("#").Length - 1; // Returns 3

How to create a Plug-in architecture

Problem

You want to create an application which could dynamically load ‘plug-ins’ at runtime.  You want to do this because:

1. you want other people to create plug-ins for your application without exposing your source code
2. you have a module which keeps changing but don't want to recompile your application every time it changes

Solution overview

1. Create an interface which all plug-ins must implement, and have it shared as an assembly referenced by both your application and the plug-ins.
2. Create a plug-in by implementing the interface, and build it as an assembly
3. Let the application know about the plug-in assembly, by using either the app.config file or any similar mechanism.
4. At run time, use Reflection (Activator.CreateInstance method) to create an object of the plug-in and store in a variable of the interface type.

Suggested references

• http://www.msdn.microsoft.com/vstudio/default.aspx?pull=/library/en-us/dnaspp/html/pluginframework.asp
• http://www.codeproject.com/csharp/Plugins.asp

Guidelines on naming conventions, standards etc.

MSDN has a paper which lays down guidelines on naming conventions, class member usages, exposing functionality etc.  This is a must-see resource for all who want to use a standard convention while coding, to create class libraries and whoever else who just want to write some good piece of code.

Online link

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnetframeworkdesignguidelines.asp

MSDN Collection link

Data binding syntaxes

Background
DataBinder.Eval and the standard explicit casting of Container.DataItem are the two syntaxes you could use while performing data binding.  Some developers are stringent on performance (they use only the standard syntax), some are concerned about maintenance (nothing but DataBinder.Eval), while some are least bothered about the syntax they use.  I have seen code filled with DataBinder.Eval where the standard Container.DataItem syntax would have been a perfect fit.  So I thought I would write a little bit on how to select the appropriate data binding syntax.

There are two data binding syntaxes you could employ when you use repeated value data binding:

• the standard syntax with explicit casting of Container.DataItem
• the DataBinder.Eval syntax

The following two expressions perform the same binding (they both bind to the 'City' column of the current data item), but uses the different syntaxes mentioned above.

1. <%# ((DataRowView)Container.DataItem)["City"] %>
2. <%# DataBinder.Eval(Container.DataItem, "City") %>

The problem with the first syntax (the standard data binding syntax) is that if the data source changes, we need to change the cast too.  Say, if the data source in the above example changes to a data reader, then we need to change the syntax to:

<%# ((DbDataRecord)Container.DataItem)["City"] %>

In other words, the standard data binding syntax is 'strongly typed'.  

DataBinder.Eval was provided as a helper method to simplify the standard data binding syntax.  Instead of you specifying the syntax (with the data item type etc.), DataBinder.Eval figures out the syntax on its own and in addition, formats the result and returns a string.

The bad thing about DataBinder.Eval is that since it uses late-bound reflection to figure out the data types of the source specified, it comes with a performance hit.

So how do we decide which data binding syntax to use?

Use DataBinder.Eval if...

• You are into control development.  When you develop controls, you are not sure what kind of data source types your control is going to be bound to.  Moreover, you also wouldn't like to force your clients to use a specific data source type.
• You don't mind a performance hit.
• You are too lazy to go to every page and change the standard syntax whenever the data source type changes :)

Use the standard syntax if...

• You want to squeeze every bit of performance out of your pages.
• You know what the data source type of a control is, and you are also sure that the data source type won't change
• You don't mind doing a CStr or a ToString wherever required
  

Both approaches have their own good and bad sides.  I hope the points above would help you decide on which one to select.