Rob Windsor's Weblog : Article

ObjectSharp's DevLounge Goes Live

windsor — Mon, 21 Apr 2008 16:03:00 GMT

ObjectSharp has always been very community focused. Our consultants run user groups; we speak at user groups, code camps and conferences; we man the experts areas at big Microsoft events; and we run our own community events like Visual Studio 2008 at the Movies. To extend our contribution to the community, we've added the DevLounge to our website. This is an area where we will post videos, articles, code, and tools so they are available on demand when you need them.

As a special kick off to the DevLounge, we are featuring a video taken at the recent Most Valuable Professional (MVP) Summit in Seattle. At the behest of ObjectSharp's Barry Gervin, Steve Ballmer donned a Team Canada hockey jersey to show Canadian developers some love.

Using Custom Business Objects with Windows Communication Foundation on the Visual Basic Community Site

windsor — Fri, 02 Nov 2007 00:10:00 GMT

An article/walktrough I wrote on Using Custom Business Objects with Windows Communication Foundation has been posted to the Visual Basic Community Site.

In my previous article, Getting Started with Windows Communication Foundation, I described the basics of creating and consuming a simple WCF service. The services demonstrated used simple types like numbers and strings but most real world applications use more complex data like customers and invoices. In this article I’ll demonstrate how to work with these custom business objects in WCF.

The complete article is available at:

http://msdn2.microsoft.com/en-us/vbasic/bb960413.aspx

Tags: [WCF]

Getting Started with Windows Communication Foundation on the Visual Basic Community Site

windsor — Thu, 16 Aug 2007 03:24:00 GMT

An article/walktrough I wrote on Getting Started with Windows Communication Foundation has been posted to the Visual Basic Community Site.

Windows Communication Foundation (WCF) is Microsoft’s next generation platform for building distributed systems. It was released as part of the .NET Framework 3.0 and is designed to consolidate and extend the APIs from previous versions of the Framework (i.e. ASP.NET Web Services, .NET Remoting, Enterprise Services (COM+), and message queuing).
Getting started with WCF isn’t difficult but there are a couple steps along the way that may not be obvious. This article will walk you through the process of creating and consuming two simple services. To achieve this goal we need to discuss service classes, service hosts, service configuration, and client proxies.

The complete article is available at:

http://msdn2.microsoft.com/en-us/vbasic/bb736015.aspx

Tags: [WCF]

Guest Blog Post on the Canadian Developers Site: Discoverability

windsor — Wed, 25 Apr 2007 20:54:00 GMT

I've got a post up on the Canadian Developer's blog talking about Discoverability and the .NET Framework.

Hmm... since this material comes from the talk I'll be doing, I guess this is a good time to plug DevTeach. You still have time to register so you can check out a ton of great sessions given by some of the top speakers in the industry (you can check out my session too if you want).

If this hasn't enticed you enough, I hear there may be a reunion of the Mad Mexican and Johnny "the Pimp" Bristowe. If this happens you know the smack will be laid down - it's something you won't want to miss.

Update: According to the comment from Donald Belcham (Robin the Boy Wonder to the Mad Mexican's Batman), the Mad Mexican will not be able to make it to the conference. He's either involved in some Central American revolution or somewhere wrestling for the Intercontinental Belt.

Application Settings Made Easy with My and Visual Basic 2005

windsor — Sun, 28 Jan 2007 08:56:20 GMT

Most applications require some configuration settings that could change over time. Classic examples would be a connection string to a database, the URL to your company web site, or the path to a log file. These settings could be stored in the application itself but this would mean that, should the setting change, the application would have to be modified, recompiled, and redeployed. A better approach would be to store the values of these settings in some external data store; traditionally this has been an INI file, a “plain” XML file, or the Windows registry.

When .NET was introduced it included built in support for configuration files which, amongst other things, could store application settings. To store settings you have to add specific XML tags and values into the configuration file so that associated classes in the Framework will be able to access them. For example, if you wanted to add a setting called AppBackColor you would include the following in your configuration file:

You would then be able to access the setting using:

Imports System.Configuration
Private Sub Form1_Load(...) Handles MyBase.Load
    Dim backColor As String
    backColor = ConfigurationSettings.AppSettings("AppBackColor")
    Me.BackColor = Color.FromName(backColor)
End Sub

There are three main issues with this procedure. First, you need to know the format of XML that’s needed in the configuration file. Second, you access the individual settings by passing their name as a string to the AppSettings object. And third, the setting value comes back to you as a string.

This means you have three potential points of failure that will all rear their ugly heads at runtime. You could potentially put improperly formatted XML in the configuration file, you could type the name of the setting incorrectly when trying to access it, and you could give the setting an invalid value (in the example above that would be something that is not a know color to .NET).

In Visual Basic 2005 you have another option. Microsoft has added both Visual Studio designers and new .NET Framework classes to make management and use of settings much, much easier. To add a new setting or to change an existing one, open your project properties, select the Settings tab, and you will be presented with the settings editor grid (see Figure 1).

Figure 1 – Settings Grid with an application setting

Each setting now has four properties instead of just the two used previously. The Name and Value are there as before but now you also have a Type and a Scope. The Type property allows us to strongly type the setting, meaning that you cannot set an initial Value that is not of the correct type and when you use the setting in code you will not have to cast or convert it from a string. The final property is Scope which can be set to Application or User. Application scoped settings are read-only and serve the same function as settings in previous versions of Visual Basic while user scoped settings are specific to an individual user and can be modified in code. User scoped settings will be discussed later in this article.

The data you’ve entered in the settings grid is saved in the configuration file as before, it’s just done for us by the designer. You don’t have to know which tags are required and what their attributes are nor do you have to worry about spelling or capitalization mistakes. Entering the settings shown in Figure 1 will result in this being added to the configuration file:

<configuration>

<applicationSettings>
    <SettingsDemo.My.MySettings>
      <setting name="AppBackColor" serializeAs="String">
        <value>AntiqueWhite</value>
      </setting>
    </SettingsDemo.My.MySettings>
</applicationSettings>
</configuration>

Now that the new setting has been configured, it can be used in your code. In this case you could use it to initialize the background color of the main form. The setting is accessed using the My namespace (which is a major addition to Visual Basic 2005) and is much cleaner than our previous example.

Private Sub Form1_Load(...) Handles MyBase.Load
Me.BackColor = My.Settings.AppBackColor
End Sub

It’s important to note that AppBackColor has become a property of the Settings class. When your application starts, Visual Basic reads the settings from the configuration file and builds these properties dynamically. Because your setting is now a property you don’t have to worry about typing the name incorrectly (you’ll get a compiler error if you do) and you get the benefits of strong typing. That is the value of the AppBackColor property is a Color, not a string that needs to be converted to a Color.

You can see that these new features address the issues found in the older settings architecture and greatly ease the process of managing and using application settings. But wait, there’s more! There’s still user scoped settings to cover.

Designer and .NET Framework support for user scoped settings, or per-user settings, is wholly new to Visual Basic 2005 (For information on how to accomplish this in previous versions of Visual Basic.NET, see Rocky Lhotka’s article entitled Storing User Configurations which can be found at http://shrinkster.com/c3x). User settings are used in much the same way as application settings but the effect is quite different.

You add a user setting in exactly the same way as an application setting but you set the Scope to User. Figure 2 shows a user setting called UserFont with an initial value of Microsoft Sans Serif, 8.25pt.

Figure 2 – Settings Grid with an application and a user setting

This new setting will update the configuration file to look like this:

<configuration>

<userSettings>
    <SettingsDemo.My.MySettings>
      <setting name="UserFont" serializeAs="String">
        <value>Microsoft Sans Serif, 8.25pt</value>
      </setting>
    </SettingsDemo.My.MySettings>
</userSettings>
<applicationSettings>
    <SettingsDemo.My.MySettings>
      <setting name="AppBackColor" serializeAs="String">
        <value>AntiqueWhite</value>
      </setting>
    </SettingsDemo.My.MySettings>
</applicationSettings>
</configuration>

And, as before, the new setting can now be used in code.

Private Sub Form1_Load(...) Handles MyBase.Load
Me.BackColor = My.Settings.AppBackColor
Me.Font = My.Settings.UserFont
End Sub

This, however, is where the similarities end. As mentioned previously, user settings are specific to a user and can be modified at runtime. So what happens when you change a setting for a user? Let’s assume you have a menu option that lets the user change the font for the main form of our application. If the user does change the font, you’ll likely want to save their choice so that you can restore it the next time the application runs. To do this you will use the UserFont setting.

When the application closes you will set UserFont to the font of the main form and then save the setting.

Private Sub Form1_FormClosed(...) Handles Me.FormClosed
My.Settings.UserFont = Me.Font
My.Settings.Save()
End Sub

When you do this a user specific configuration file called user.config will be created in a folder under the Documents and Settings for the person currently logged in to Windows. This file will store the setting data specific to that user.

Nice? It gets even better. You can actually achieve the same result without any code. The Windows Forms designer supports binding user settings to properties of forms or controls. For example, you could bind the UserFont setting to the Font property of our application’s main form (Form1). In the Properties Window for Form1 find (ApplicationSettings) and expand it. Then select (PropertyBinding) and click the button with the ellipses to open the binding editor form (see Figure 3). Finally, select the Font property, click the dropdown, and select UserFont from the list.

Figure 3 – Binding a user setting to a property

With this done you no longer need to set the Font property in the Form’s Load event and you don’t need to set UserFont in the FornClosed event either. The data binding handles this for us.

The last thing to mention is the call to My.Settings.Save which you saw in the FormClosed event. This actually wasn’t necessary, it was added it for completeness. If you look in the Application tab of your Project Properties you’ll see a CheckBox with the caption “Save My.Settings on Shutdown” (see Figure 4). If this is checked (and it is by default) then Visual Basic will automatically save user settings just before the application terminates. The combination of this option and the visual tools to bind settings to form and control properties give you a no-code solution for implementing user settings.

Figure 4 – Enabling the automatic saving if user settings.

As you’ve seen, the addition of My to Visual Basic 2005, new classes to the .NET Framework 2.0 and new designers to Visual Studio 2005 vastly improves our ability to manage and use application and user specific settings in our applications.

Some Specifics on Generics

windsor — Wed, 03 Jan 2007 09:07:56 GMT

Generics are the most significant language addition to .NET 2.0. They allow for code re-use in ways not previously available and make it much easier to write type-safe, better performing code. That is, they help you turn runtime exceptions into compile-time errors while making your application run faster. Sound good?

What’s the Problem?
The classic example used to demonstrate the problem Generics solve is the general purpose collection. In .NET 1.1 collection classes like the ArrayList and HashTable are object based so they can store data of any type. Unfortunately this benefit has a cost, the lack of type safety. The user of the ArrayList cannot restrict the types it stores, which can potentially lead to runtime errors.

Dim al As New ArrayList()

al.Add(11)

al.Add(42)

al.Add(18.0)  ' will cause a runtime error in the for loop

Dim sum As Integer = 0

For i As Integer = 0 To al.Count

    sum += CInt(al(i))

Next

ArrayList al = new ArrayList();

al.Add(11);

al.Add(42);

al.Add(18.0);  // will cause a runtime error in the for loop

int sum = 0;

for (int i = 0; i < al.Count; i++) { sum += (int)al; }

The solution to this problem in .NET 1.1 is to create a strongly-type collection class by inheriting from CollectionBase (or DictionaryBase is you want HashTable like functionality). While this task is not difficult it is tedious and leads to code bloat. You have to write almost exactly the same code for each and every type which requires a strongly-typed collection.

Public Class IntCollection

    Inherits CollectionBase

    Default Public Property Item(ByVal index As Integer) As Integer

Get

            Return (CType(List(index), Integer))

        End Get

        Set(ByVal Value As Integer)

            List(index) = Value

        End Set

    End Property

    Public Function Add(ByVal value As Integer) As Integer

        Return (List.Add(value))

    End Function

    Public Function IndexOf(ByVal value As Integer) As Integer

        Return (List.IndexOf(value))

    End Function

    Public Sub Insert(ByVal index As Integer, ByVal value As Integer)

        List.Insert(index, value)

    End Sub

    Public Sub Remove(ByVal value As Integer)

        List.Remove(value)

    End Sub

End Class

public class IntCollection : CollectionBase

    public int this[int index]

        get { return ((int)List[index]); }

        set { List[index] = value; }

    public int Add(int value)

        return (List.Add(value));

    public int IndexOf(int value)

        return (List.IndexOf(value));

    public void Insert(int index, int value)

        List.Insert(index, value);

    public void Remove(int value)

        List.Remove(value);

A second problem is performance. Value types need to be boxed when being added to the collection and the unboxed when they are retrieved. This is a “double whammy” because not only do you pay the penalty for boxing but you also add more and more work to the garbage collection mechanism as the collection grows. Even if you’re storing reference types there is still some penalty for casting.

Using Generics
Generics are designed to address the issues stated above without sacrificing developer productivity. The idea is to allow classes to be parameterized by the types they store and manipulate. The type parameter or parameters, which are enclosed in angle brackets and separated by commas, can be added to a class or method declaration. The type parameter acts as a placeholder for the actual type that will be used at runtime. For example you could create a generic Stack class:

Public Class Stack(Of T)

    Private _items As New List(Of T)

    Public Sub Push(ByVal item As T)

        _items.Add(item)

    End Sub

    Public Function Pop() As T

        If _items.Count = 0 Then

            Throw New InvalidOperationException("Stack is empty")

        End If

        Dim index As Integer = _items.Count - 1

        Dim item As T = _items(index)

        _items.RemoveAt(index)

        Return item

    End Function

End Class

public class Stack<T> {

    private List<T> _items = new List<T>();

    public void Push(T item) { _items.Add(item); }

    public T Pop() {

        if (_items.Count == 0) {

            throw new InvalidOperationException(“Stack is empty”);

        int index = _items.Count – 1;

        T item = _items[index];

        _items.RemoveAt(index);

        return item;

In this case the type parameter is T (it is common practice to use a single capital letter as the name for a type parameter but you are free to use more descriptive names if you choose) so the type would be know as “Stack of T”. T is used as the type for the regular parameter to Push and the return type of Pop. It is interesting to note that it is also used as the type argument in the construction of the internal List of items. The type argument defines the specific type you wish to use for that instance of the generic class.

The .NET Framework 2.0 adds several new generic collection classes in the System.Collections.Generic namespace, the most commonly used being List<T> (the generic version of ArrayList) and Dictionary<K, T> (the generic version of HashTable).

Dim al As New List(Of Integer)

al.Add(11)

al.Add(42)

al.Add(18.0)  ' will cause a complie time error

Dim sum As Integer = 0

For i As Integer = 0 To al.Count

    sum += al(i)  ' no cast or unboxing required

Next

List<int> al = new List<int>();

al.Add(11);

al.Add(42);

al.Add(18.0);  //will cause a complie time error

int sum = 0;

for (int i = 0; i < al.Count; i++) {

    sum += al; // no cast or unboxing required

Generic Methods
You have seen adding type parameters to classes, you can do the same thing for methods. This can be done even if the class itself is not generic. To do this you use the same syntax style as with classes, adding the type parameter after the name of the method but before the regular parameter list.

Private Class Utility

    Public Function Max(Of T)(ByVal a As T, ByVal b As T) As T

        If a > b Then

            Return a

        End If

        Return b

    End Function

End Class

' usage of Max

Public Sub MaxTest()

    Dim u As New Utility()

    Dim i As Integer = u.Max(Of Integer)(7, 11)

    ' Use type inference

    Dim d As Double = u.Max(10.0, 42.42)

End Sub

private class Utility

    public T Max<T>(T a, T b)

        if (a > b) { return a; }

        return b;

// usage of Max

public void MaxTest()

    Utility u = new Utility();

    int i = u.Max<int>(7, 11);

    double d = u.Max(10.0, 42.42);  //OK, uses type inference

When using generic methods, the C# compiler is able to infer the type arguments from the types of the regular parameters passed so you do not have to explicitly state them.

Constraints
Time to “fess up”, the code for the Max method in the example directly above does not compile. The condition (a > b) causes a compiler error because it does not have meaning for all possible values of T. To get it to work you need to modify the code somewhat.

Public Class Utility

    Public Function Max(Of T)(ByVal a As T, ByVal b As T)

        If a.CompareTo(b) > 0 Then

            Return a

        End If

        Return b

    End Function

End Class

public class Utility

    public T Max<T>(T a, T b)

        if (a.CompareTo(b) > 0) { return a; }

        return b;

OK, it still doesn’t compile. Using CompareTo is a valid solution but it requires that the type assigned to T implement the IComparable interface. You need to indicate this constraint to the C# compiler. This requires one additional code change.

Public Class Utility

    Public Function Max(Of T As IComparable(Of T)) _

        (ByVal a As T, ByVal b As T)

        If a.CompareTo(b) > 0 Then

            Return a

        End If

        Return b

    End Function

End Class

public class Utility

    public T Max<T>(T a, T b) where T : IComparable<T>

        if (a.CompareTo(b) > 0) { return a; }

        return b;

Other common constraints are: requiring a particular base type for the type argument, indicating that the type argument must be a reference type or value type, and indicating that the type argument must have a default constructor.

Conclusion
Generics are better for you than Broccoli (assuming that easier to write, type-safe, performant code is important to you, if not the please do a Google search for Ruby to find material more to your taste). As you work with .NET 2.0 you will begin to get the “Zen of Generics” and then you will see that the immediate benefits of strongly-typed collections are really just the tip of the Iceberg<T> where T : Big, ICold.

Keep Client Applications Responsive with the BackgroundWorker

windsor — Thu, 09 Nov 2006 09:58:00 GMT

Many applications need to perform some kind of long-running task like downloading a file, performing a complex calculation, or retrieving data from a database. Executing these tasks can make your application become unresponsive and end up making your users anxious. Take too long performing the task and the user will be looking for the Task Manager to kill your application.

The solution to this problem is to execute the long-running task on a second (or background) thread. This allows the user interface thread to continue working keeping your application responsive, but it presents you with a new problem. Creating multi-threaded applications is difficult - well actually it’s easy - it’s doing so properly, following all the rules, and not coding yourself into an all night debugging session that’s truly hard.

To help address this issue Microsoft added the BackgroundWorker component to .NET 2.0. This component is easy to use and understand and makes programming multi-threaded applications (without explicitly creating and managing threads) much safer for the developer. The exploration of the BackgroundWorker will be done through the creation of a demo application.

For a more comprehensive discussion of the topics covered in this article and to see how to achieve the same results using previous versions of .NET, see Chris Sells three-part series entitled Safe, Simple Multithreading in Windows Forms (http://shrinkster.com/ddm).

Let's assume you have a simple application with a Button and a ProgressBar. The code below will simulate a long-running task by putting the user interface thread to sleep, one half second at a time, in a loop. The loop is used to allow the program to report progress back to the user via the ProgressBar.

Private Sub Button1_Click(...) Handles Button1.Click
Button1.Enabled = False
For i As Integer = 1 To 10
ProgressBar1.Value = i * 10
Threading.Thread.Sleep(500)
Next
MessageBox.Show("Done", "Demo")
Button1.Enabled = True
End Sub

As it stands, clicking the Start Button will begin the long-running task and, while the ProgressBar will be updated as we iterate through the loop, the rest of the application will be unresponsive. You will not be able to move or resize the form until the loop completes. The remainder of this post will discuss how to convert this code to run the loop on a background thread via the BackgroundWorker component. It will also show how to upgrade the application to allow the long-running task to be cancelled.

First, declare a private field for the BackgroundWorker. Then in the Form’s Load event handler, create the instance of the BackgroundWorker and set its WorkerReportsProgress and WorkerSupportsCancellation properties to True. These properties are set to False by default as a performance optimization.

Private WithEvents _worker As BackgroundWorker
Private _working As Boolean
Private Sub Form1_Load(...) Handles MyBase.Load
_worker = New BackgroundWorker
_worker.WorkerReportsProgress = True
_worker. WorkerSupportsCancellation = True
End Sub

Create an event hander for the BackgroundWorker’s DoWork event and copy the existing code from the Button’s Click event hander to the newly created method. The Button is going to be used to both start the long-running task as well as cancel it. In the Click event handler check if the BackgroundWorker is currently busy; if it is signal a request to cancel the task by calling CancelAsync otherwise begin the task by calling RunWorkerAsync. It is important to note that the call to CancelAsync does not immediately terminate the task, it just signals a request to cancel. The code running the task must check for the request and handle it appropriately (see below).

Private Sub Button1_Click(...) Handles Button1.Click
If _worker.IsBusy Then
    _worker.CancelAsync()
Else
    Button1.Text = "Cancel"
    _worker.RunWorkerAsync()
End If
End Sub

The code copied to the DoWork event handler needs to be modified slightly. The code in this event handler executes on a background thread so it cannot safely update the user interface, thus the line that originally set the Value property of the ProgressBar has to be changed. Replace this line with a call to the ReportProgress method of the BackgroundWorker passing the percent completed as a parameter. This will trigger the ProgressChanged event where we can safely update the ProgressBar. In addition, this code has to check for a request from the user to cancel the task which can be done by inspecting the CancellationPending property of the BackgroundWorker.

Private Sub _worker_DoWork(...) Handles _worker.DoWork
For i As Integer = 1 To 10
    _worker.ReportProgress(i * 10)
    Threading.Thread.Sleep(500)
    If _worker.CancellationPending Then
      e.Cancel = True
      Exit For
    End If
Next
End Sub

Private Sub _worker_ProgressChanged(...) Handles _worker.ProgressChanged
ProgressBar1.Value = e.ProgressPercentage
End Sub

Finally, the BackgroundWorker raises the RunWorkerCompleted event to notify the user interface that long-running task is done, either because it completed normally or because it was cancelled.

Private Sub _worker_RunWorkerCompleted(...) Handles _worker.RunWorkerCompleted
Dim msg As String = "Done"
If e.Cancelled Then
msg = "Cancelled"
End If
Button1.Text = "Start"
MessageBox.Show(msg, "Demo")
End Sub

This short example demonstrates the basic use of the BackgroundWorker. That is executing a long-running task on a background thread, showing progress, and allowing the user to cancel.