The Queue<T> class (and Stack<T> too) of the .NET Framework from Microsoft is implemented using an array. While this is a perfectly good approach, I think that a Linked List based implementation could be desired in some situations (specifically when the size of the queue is not fixed).

Since the implementation alone would be rather simple for a post, I’ll show you how to implement Unit Testing with the class using Nunit. Although this is a rather simple class to test I think it will show the basic concepts behind unit testing.

If you’ve ever worked with relatively large UpdatePanels maybe you’ll have had a problem: blocking the user some elements while the asynchronous postback is running. When working with local or LAN environments, the async responses might be fast, but over the internet, or on large calculations the async postback may take a while. During this period, you may want to block the UpdatePanel controls so the user can’t trigger another postback or do any other operations on that UpdatePanel. I’ll show you an easy way to do so by using the AJAX framework for .NET and jQuery and one of its plugins: blockUI.

For those who don’t know jQuery, it’s an opensource Javascript framework that is going to be embedded on future versions of Visual Studio. It’s a very good framework because of its simplicity and its extensibility, having lots of plugins. One of those plugins is the blockUI plugin, which allows you to block and unlock any part of the DOM at will.

One of the interesting new things on the .NET platform is the recent addition of Python and Ruby to the CLR. Both versions for .NET are called IronPython and IronRuby respectively, and they provide some new and good things to the platform.

Python and Ruby lovers will see now that they can use all the library and features of the .NET platform programming in their favorite scripting language. Since both of them are object oriented, you can now write fully fledged apps using either of them.

However, there's another interesting application for IronPython and IronRuby: adding scripting support for your existing .NET applications. This can be a very useful and powerful way to extend your applications and give the user freedom to program their own mini programs, scripts or whatever in your applications. It could be good for defining rules, assigning and calculating values, etc.

I'll provide a simple class you can use to add scripting to your application. I'll use IronPython in this example.

First of all, you have to download IronPython and install it, and add the references to the assemblies on your project references.

The usual way to proceed in those cases is to provide the user of some local variables you give them access to, execute the script, and then recover the values of those or new variables. To do so, You can use a class similar to this one:

using System;
using System.Collections.Generic;
using System.Text;
using IronPython.Hosting;
using Microsoft.Scripting.Hosting;
using Microsoft.Scripting;

namespace Scripting
{
	internal class PythonEngine
	{
        ScriptEngine m_engine;
        ExceptionOperations m_exceptionOperations;
        SortedDictionary<string, object> m_inputVariables;
        string m_script;

        internal PythonEngine()
        {
            m_engine = Python.CreateEngine();
            m_exceptionOperations = m_engine.GetService<ExceptionOperations>();
        }

        internal SortedDictionary<string, object> ScriptVariables
        {
            set { m_inputVariables = value; }
        }

        internal string Script
        {
            set { m_script = value; }
        }

        internal ExceptionOperations ExceptionOperations
        {
            get { return m_exceptionOperations; }
        }

        internal SortedDictionary<string, object> Execute()
        {
            //Create structures
            SourceCodeKind sc = SourceCodeKind.Statements;
            ScriptSource source = m_engine.CreateScriptSourceFromString(m_script, sc);
            ScriptScope scope = m_engine.CreateScope();
            //Fill input variables
            foreach (KeyValuePair<string, object> variable in m_inputVariables)
            {
                scope.SetVariable(variable.Key, variable.Value);
            }
            SortedDictionary<string, object> outputVariables = new SortedDictionary<string, object>();
            //Execute the script
            try
            {
                source.Execute(scope);
                //Recover variables
                foreach (string variable in scope.GetVariableNames())
                {
                    outputVariables.Add(variable, scope.GetVariable(variable));
                }
            }
            catch (Exception e)
            {
                string error = m_exceptionOperations.FormatException(e);
                //Do something with the pretty printed error
                throw;
            }
            return outputVariables;
        }
	}
}

Usage of this class is pretty simple. You have to provide the object the script you want to execute and the input variables the script will have available as local variables. Once this is done, you have to call the Execute method, and this method will either return the output variables of the execution of the resulting script, or throw an exception.

By default in C# 3.0 ComboBox controls don’t provide support for showing drop-down list items if they exceed the width of their parent ComboBox, like this one:

This is annoying because users cannot read properly the information. To solve that problem, all we have to do is derive the ComboBox class and override the DropDown event as follows:

public class ComboBoxEx : ComboBox
{
	public ComboBoxEx()
		: base()
	{
		DropDown += new EventHandler(event_DropDown);
	}

	void event_DropDown(object sender, EventArgs e)
	{
		try
		{
			ComboBox comboBox = (ComboBox)sender; // Catch the combo firing this event
			int width = comboBox.Width; // Current width for ComboBox
			Graphics g = comboBox.CreateGraphics(); // Get graphics for ComboBox
			Font font = comboBox.Font; // Doesn't change original font

			//checks if a scrollbar will be displayed.
			int vertScrollBarWidth;
			if (comboBox.Items.Count > comboBox.MaxDropDownItems)
			}
				//If yes, then get its width to adjust the size of the drop down list.
				vertScrollBarWidth = SystemInformation.VerticalScrollBarWidth;
			}
			else
			{
				//Otherwise set to 0
				vertScrollBarWidth = 0;
			}
			//Loop through list items and check size of each items.
			//set the width of the drop down list to the width of the largest item.
			int newWidth;
			foreach (string s in comboBox.Items)
			{
				if (s != null)
				{
					newWidth = (int)g.MeasureString(s.Trim(), font).Width + vertScrollBarWidth;
					if (width < newWidth)
						width = newWidth;
				}
			}
			// Finally, adjust the new width
			comboBox.DropDownWidth = width;
		}
		catch {  }
	}   
}

The following picture shows the results of using the above control instead of the default one:

SQL Server has a special extended stored procedure called xp_cmdshell. This procedure has a lot of power: it allows to execute any command line code on the machine hosting the SQL Server.

Imagine you want to list all the files on C: on the SQL Server Windows host: you could write a T-SQL statement like this one:

EXECUTE master..xp_cmdshell 'dir c:'

This stored procedure, however, is a very dangerous one, as it would allow to execute harmful code. This is the reason why it's disabled by default. Even when enabled, only users on the sysadmin role can use it.

If you ever need some users the ability to run only some specific commands with xp_cmdshell, you can use the method I'll explain below, making use of the EXECUTE AS modifier of the stored procedure definitions in T-SQL.