To enable this feature, you need to uncheck “Disable script debugging (Internet Explorer)” in the “Advanced” tab of the “Internet Options” dialog in IE:

Debugging is now enabled:

Doing this will also give you access to Visual Studio’s Script Explorer which allows you to view and trace through the stack of scripts that are running within your ASP.NET application behind the scenes:

Warning: Client-side script debugging does slow down the application quite a bit during development. It would be wise to only have this feature enabled when you need to debug javascript.

Note: This information assumes that you are using IE as your default development browser. If you would like to change default browsers, select your website project in the Solution Explorer, and then select “Browse With…” from the File menu:

Alternatively, while the application is running in Debug mode, you can attach the process to another browser and run the two browsers in tandem. Select “Attach to Process…” from the Debug menu to accomplish this:

1. Create an XML schema definition file (xsd) to define the data being stored.
2. Create a Serializable class based on the xsd so the data may be instantiated/accessed in the code.
3. Use serialization and deserialization to load and unload the user settings.

Using xsd.exe to generate a serializable class.
The first step I took was to create an XML schema definition file to represent my user settings data.  Once the schema was finished, I used the XML Schema Definition Tool (xsd.exe) to generate a serializable class from the schema.  This executable is part of the .NET SDK and is a real time saver. Use the following command line parameters to generate a serializable class based on an xsd file:

xsd.exe -c -l:c# -n:[namespace for the generated class] [XML Schema Definition File]

Example:

xsd.exe -c -l:c# -n:MyProgram.Utilities MyUserSettings.xsd

This example will create a serializable class called MyUserSettings.cs.

Serialization and Deserialization
Simply stated, serialization is the process of converting an object instance into a stream of bytes, text, XML or other formats so that it can be persisted into storage medium or transfered across a network. Deserialization is the opposite process which converts the persisted data back into an object instance. The following are sample methods for each process:

using System;
using System.IO;
using System.Runtime.Serialization.Formatters.Binary;
using System.Text;
using System.Xml;
using System.Xml.Serialization;

namespace MyProgram.Utilities
{
    public static class Serialization
    {
        public enum SerializationMethod { Binary, XML };

        public static void Serialize(string sFilePath, Type type, object objectToSerialize, SerializationMethod serializationMethod)
        {
            if (!File.Exists(sFilePath))
            {
                return;
            }

            Stream writeStream = null;
            XmlTextWriter xtw = null;
            try
            {
                writeStream = File.Open(sFilePath, FileMode.Truncate);
                if (serializationMethod == SerializationMethod.XML)
                {
                    XmlSerializer xs = new XmlSerializer(type);
                    xtw = new XmlTextWriter(writeStream, null);
                    xs.Serialize(xtw, objectToSerialize);
                }
                else if (serializationMethod == SerializationMethod.Binary)
                {
                    new BinaryFormatter().Serialize(writeStream, objectToSerialize);
                }
            }
            finally
            {
                if (xtw != null)
                {
                    xtw.Close();
                }
                if (writeStream != null)
                {
                    writeStream.Close();
                    writeStream.Dispose();
                }
            }
        }

        public static object Deserialize(string sFilePath, Type type, SerializationMethod serializationMethod)
        {
            if (!File.Exists(sFilePath))
            {
                return Activator.CreateInstance(type);
            }

            Stream stream = null;
            object deserializedObject = null;
            try
            {
                stream = File.OpenRead(sFilePath);
                if (serializationMethod == SerializationMethod.XML)
                {
                    XmlSerializer xmlSerializer = new XmlSerializer(type);
                    deserializedObject = xmlSerializer.Deserialize(stream);
                }
                else if (serializationMethod == SerializationMethod.Binary)
                {
                    deserializedObject = new BinaryFormatter().Deserialize(stream);
                }
            }
            finally
            {
                if (stream != null)
                {
                    stream.Close();
                    stream.Dispose();
                }
            }
            return deserializedObject;
        }
    }
}

Note that these methods support both XML (human readable) and binary (gibberish) de/serialization. This comes in handy if you want to prevent the settings files from being tampered with in a production environment, but you’d prefer them easier to work with during development. Using preprocessor directives, you can do something like the following to make the files human readable at development time, but garbled when they are released into the wild:

MyUserSettings userSettings = GetMySettings();
#if DEBUG
Serialization.SerializationMethod serializationMethod = Serialization.SerializationMethod.XML;
#else
Serialization.SerializationMethod serializationMethod = Serialization.SerializationMethod.Binary;
#endif
Serialization.Serialize(sFullSettingsFileName, typeof(MyUserSettings), userSettings, serializationMethod);

• Disable/enable the Minimize button via the Form.MinimizeBox property
• Disable/enable the Maximize button via the Form.MaximizeBox property
• Show/hide the entire ControlBox via the Form.ControlBox property

However, you may want to allow maximizing and minimizing, but remove the user’s ability to close the application using the close button for any number of reasons. For example:

• You want to run some process that cannot be cancelled midway through.
• You want to ensure a user completes some number of tasks before being able to exit.

Unfortunately, this functionality is not supported by default. One must leverage the unmanaged code of the Windows API to achieve this behavior:

using System;
using System.Runtime.InteropServices;
using System.Windows.Forms;

public class SuperForm : Form
{
    private const int MF_BYPOSITION = 0x400;

    protected void DisableCloseButton()
    {
        IntPtr hMenu = GetSystemMenu(this.Handle, false);
        int menuItemCount = GetMenuItemCount(hMenu);
        RemoveMenu(hMenu, menuItemCount - 1, MF_BYPOSITION);
        DrawMenuBar((int)this.Handle);
    }
    protected void EnableCloseButton()
    {
        GetSystemMenu(this.Handle, true);
        DrawMenuBar((int)this.Handle);
    }

    // Win32 API declarations
    [DllImport("User32")]
    private static extern IntPtr GetSystemMenu(IntPtr hWnd, bool bRevert);
    [DllImport("User32")]
    private static extern int GetMenuItemCount(IntPtr hWnd);
    [DllImport("User32")]
    private static extern int RemoveMenu(IntPtr hMenu, int nPosition, int wFlags);
    [DllImport("User32")]
    private static extern IntPtr DrawMenuBar(int hwnd);
}

Notice that I incorporated this functionality into a base class that all your forms can inherit from to gain this ability.

Creating an interop assembly with Visual Studio
Enter the “Add reference” dialog of your project, browse for your registered COM server and select it. Now take a look at the properties of the newly created reference. It is actually pointing to a new assembly called Interop.COMServerName.dll: If your COM server is foo.dll, the resulting assembly is called Interop.foo.dll. You will find this assembly in your bin directory after you build.

If your project uses an .snk or .pfx for strong naming, the interop assembly will also be strong named using that file.

A major limitation of this method I found was the fact that you can’t change the version number of the interop assembly. It is always 1.0.0.0. Bummer.

Creating an interop assembly with Type Library Importer
If you need more control, then you should use the Type Library Importer (tlbimp). This application is included with the .NET SDK.

Running the following command will create an interop assembly with a version number of your choosing:
Using our foo.dll example:

tlbimp foo.dll /out:Interop.foo.dll /asmversion:2.0.0.0

If you need the interop assembly strongly named, you can do that also. If you are using an .snk, use the following:

tlbimp foo.dll /out:Interop.foo.dll /asmversion:2.0.0.0 /keyfile:MyKey.snk

If you are using a .pfx for strong naming, it’s a bit trickier. You will also need to leverage the Strong Name Tool (sn) to create a keycontainer:

echo Prompts you for .pfx password
sn -i MyKey.pfx KeyContainerName

tlbimp foo.dll /out:Interop.foo.dll /asmversion:2.0.0.0 /keycontainer:KeyContainerName

echo Housecleaning.  Removes the key container from memory.
sn -d KeyContainerName

Now add it as a reference and you’re good to go!

Global Assembly Cache
The GAC is special because it allows a pc to store multiple versions of the same .NET assembly. This is made possible by strong naming. More importantly, it provides a centralized location for .NET assemblies that need to be shared across multiple applications.

When viewing the GAC via the Windows shell, you go here: C:\Windows\Assembly. However, the Explorer-like UI actually represents an aggregate of files and folders. Windows is just trying to make it look nice and user friendly for us.

Tricking Visual Studio
To trick Visual Studio into referencing a GAC assembly, you can do the following:
1.) Reference a copy of the assembly that is located outside of the GAC via the Add Reference dialog. You can throw a copy on your Desktop and then reference it from there. It doesn’t matter what the file’s location is.
2.) Install the assembly into the GAC. There are a number of ways to do this. The easiest way is to use the “Microsoft .NET Framework 2.0 Configuration” app. You can find it by going to Control Panel –> Administrative Tools. Once in the app, click “Manage the Assembly Cache” and then “Add an Assembly to the Assembly Cache.”
3.) Delete the assembly file that you referenced in step 1. Go into Visual Studio and refresh the project. The path of the reference should have automatically changed over to its GAC location (C:\Windows\assembly\…).
4.) You may want to set the reference’s “Copy Local” property to False so that the build does not produce a copy of the GAC assembly in the bin folder (to avoid confusion). In doing so, you can be confident that your app is in fact hitting the GAC!

For a freebie suite of controls, I was impressed.  The toolkit includes all your basic controls (Label, ComboBox, etc), 38 in all, and are very customizable.  You can also apply out of the box themes, such as Office2007, also free.  It integrates seemlessly into Visual Studio (I was using VS2005) and includes a very nice demo app that shows off what all the controls can do.

Also in the Krypton family are the Ribbon, tab control, and workspace control.  These are upgrades that you have to pay for, but still cheap when you consider all the very expensive alternatives out there.

Next time you are building an little app from the ground up, consider using these controls.  You should be able to make your app look a ton better at no extra cost.

Use it. ‘Nuf said.

I recently came across two cases where parameters are valid if passing by value, but result in compilation errors after adding “ref”. Consider the following member and method:

// SuperDataTable inherits from DataTable
// Indexing a SuperDataTable yields a SuperDataRow
// which inherits from DataRow.
private SuperDataTable mySuperDataTable = new SuperDataTable();

public void DoSomethingSuper(ref DataRow myDataRow)
{
	return;
}

Now examine the following three scenarios:

// #1 You receive a compiler error "A property or indexer
// may not be passed as an out or ref parameter"
DoSomethingSuper(ref mySuperDataTable[0]);

// #2 You receive a compiler error "Cannot convert from
// 'ref SuperDataRow' to 'ref DataRow'
SuperDataRow mySuperDataRow = mySuperDataTable[0];
DoSomethingSuper(ref mySuperDataRow);

// #3 Only does it work in the following manner, when you
// explicitly "upcast" the row to the exact type in the
// signature of the method
DataRow myDataRow = mySuperDataTable[0];
DoSomethingSuper(ref myDataRow);

Try it again, this time passing by value. No compiler errors! I probably am just lacking an intimate understanding of “ref”, but this came out of left field for me and I haven’t seen it documented online. Can anybody fill me in as to why scenarios #1 and #2 don’t work?

There are many solutions to this problem which include various WordPress.org plug-ins.  The problem with the plug-ins is that they don’t work with freebee WordPress.com blogs.  The simplest solution that I found for WordPress.com blogs was to simply wrap the code you want to post in “sourcecode” tags and let javascript take care of the rest. Implementing this is easy because you don’t have to worry about a big blob of HTML. All that is required is the code you want to paste and the javascript tags. Example:

static void Main(string[] args)
{
      Console.Out.WriteLine("Hello World!");
      return;
}

Being the perfectionist that I am, I wanted to see if I could get the code to look closer to the default fonts and colors used in Visual Studio. Thanks to this posting, I discovered pastebin.com.  It does a nice job of converting source code into html.  And it has syntax highlighting for most languages, including C#.  To streamline the process, I wrote a parser.  This code will parse the full source of the pastebin output, yank out the relevent html, and add style to make it look close to Visual Studio.  The following source code is a solution to the problem and also a demonstration. Which method do you think looks better?