Windows Forms is a Maintenance Risk

People say that WPF is a pretty big change from the Windows Forms technology of yesteryear, but there are also people who have invested considerable time and money into Windows Forms solutions that aren’t eager to rewrite their apps yet again. I can understand that—it takes time to develop things, and rewriting things for the sake of using the latest and greatest is not usually something that keeps projects on time and on budget.

But any new development should definitely be written in WPF.

Here’s a snippet of Windows Forms code that keeps a TextBox on the screen synchronized with a Quantity field on an Order object:

MyEditor.cs
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
public class MyEditor : UserControl
{
    private System.Windows.Forms.TextBox quantityTextBox;
 
    public MyEditor()
    {
        InitializeComponent();
    }
 
    private void InitializeComponent()
    {
        quantityTextBox = new System.Windows.Forms.TextBox();
        quantityTextBox.TextChanged += new System.EventHandler(quantityTextBox_TextChanged);
        // ...more auto-generated noise
    }
 
    public void SetOrder(Order order)
    {
        _order = order;
        _order.PropertyChanged += order_PropertyChanged;
        quantityTextBox.Text = _order.Quantity.ToString();
    }
 
    private void quantityTextBox_TextChanged(object sender, EventArgs e)
    {
        long qty;
        if (long.TryParse(quantityTextBox.Text, out qty))
        {
            _order.Quantity = qty;
            quantityTextBox.BackColor = Color.White;
        }
        else
        {
            quantityTextBox.BackColor = Color.Pink;
        }
    }
 
    private void order_PropertyChanged(object sender, PropertyChangedEventArgs e)
    {
        if (e.PropertyName == "Quantity")
        {
            quantityTextBox.Text = _order.Quantity.ToString();
        }
    }
}

And in WPF:

MyEditor.xaml
1
2
3
4
5
<UserControl x:Class="MyEditor"
                         xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
                         xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <TextBox Text="{Binding Path=Quantity}"/>
</UserControl>
MyEditor.xaml.cs
1
2
3
4
5
6
7
8
9
10
11
12
public partial class MyEditor
{
    public MyEditor()
    {
        InitializeComponent();
    }
 
    public void SetOrder(Order order)
    {
        this.DataContext = order;
    }
}

Which one would you rather maintain? —DKT

PowerShell Deployment Options are Awful

I once looked into using Powershell as a foundation for an application that was to be very heavily powered by scripts underneath. It seemed like an idea with a lot of promise—most of the libraries it was to work with were written in .NET, the users were comfortable with scripting, and it would have been easy to expose GUI components in a scriptable way (think VBA for Office)—however, actually getting the thing deployed would have been a totally different manner.

Most firms lock down end-user machines. This makes for a more secure and easier to manage network, but it makes deploying an application an absolute nightmare when an application requires a non-trivial installer and administrative privileges to use.

And that brings me to the title of this post. Powershell deployment options are awful. Considering that Powershell is written largely (exclusively?) in .NET, it’s unbelievable that an installer has to be run, files need to be installed in system directories, and registry keys need to be written. About 99% of what it does can be done in pure .NET, and any app written in pure .NET can be copied to a directory and run as long as its dependencies are in the same directory or in the GAC. Life would have been much simpler for me if I could just include the Powershell .NET assemblies, deploy them with my application, and run Powershell scripts.

And then let’s say I do end up being able to deploy PowerShell properly, with all its funky registry keys and whatever else that installer does; what am I supposed to do with any PSSnapIns that I’m dependent on?

Somewhere on the Microsoft campus, there needs to be a giant poster called “Lessons Learned”. It should include at least the following bullet points:

  • No Clippy. Cartoons don’t help people get work done—functional software does.
  • People like XCOPY deploy—installers are obnoxious.

Well, they removed Clippy from Office 2007. Right now, .NET apps are so simple to deploy it’s criminal. So what’s the deal with Powershell? —DKT