Composite UI Application Block - Soup to Nuts - Getting Started
I’m currently helping some teams move towards creating Smart Client applications. As part of that move, I’m also introducing them to use the Composite UI Application Block (CAB) which will ease the pain of building the UI, separating it, and generally making it a better life than just writing plain old boring Windows Form apps.
So this begins a series of blogs on writing applications using CAB. The series starts super simple, with a bare minimal example and compares the differences between a regular WinForm app and one written using the CAB. In this series, we’ll just keep building on each example to another and finish off with an n-tier, service-oriented solution that employs the CAB and does some pretty cool stuff. I won’t reveal what the app is but you can figure it out as we go along.
The next series to follow-up this series will go beyond just the CAB and describe the Smart Client Software Factory (SCSF) which not only uses CAB but adds a million other things. Think of CAB as Windows Forms on steroids and the Smart Client Software Factory as CAB on steroids. It’s going to be a blast.
By now, you’re probably wondering why a little ol’ SharePoint MVP like me is blubbering on about writing Smart Clients but hang in there, they’ll be more than your share of SharePoint stuff by the time we’re finished.
Rules of Engagement
Just a couple of notes on this blog series. All the examples are written in C#. If you’re looking for VB.NET samples you won’t get them here as I just prefer C# (feel free to build your sample in VB.NET if that’s your cup’o’tea). Also these samples are built with Visual Studio 2005 just because a) the CAB is .NET 2.0 based and b) the SCSF is Visual Studio 2005 based. I think there might be a version of CAB for 1.1 (not sure) but Smart Client development and Click Once was never great with .NET 1.1 and it’s 2006 so get off yer 1.1 butts and move on up to the new neighbourhood.
Getting Started
Okay, let’s get this party started. We have to walk before we run so this blog entry is just going to create the minimal app. We’ll highlight the differences between what you get with an auto-generated WinForm app vs. what you need to do to create the minimal CAB app. It doesn’t do anything at this point (not even “Hello World” on the screen) but every journey starts with the first step.
To get going:
- Install the CAB using the link above and follow the instructions for installation
- Create a new Windows Application using the Create Project option in Visual Studio. Just the typical application (call it WindowsApplication1) with a single Windows Form.
- Add a reference to the following assemblies: Microsoft.Practices.Composite.UI; Microsoft.Practices.Composite.UI.WinForm; Microsoft.Practices.ObjectBuilder.
Next we’re going to create a WorkItem. A WorkItem is A WorkItem is a run-time container for components that are working together to fulfill a use case. These components may consist of SmartParts (no, not those SmartParts), controllers, services, UIElements, and other components. You can use a WorkItem to encapsulate different use cases or areas of an application to share events and state. However, if you overuse WorkItems and make them too fine grained, or if you build your WorkItem classes inconsistently, you may end up with an application that is difficult to maintain. You need at least one WorkItem in your application so let’s create one:
- Create a new class called Form1WorkItem
- Add Microsoft.Practices.CompositeUI to the using statements at the top of the file
- Change the Form1WorkIem class to inherit from the WorkItem class
Your Form1WorkIem class should look like this now:
1 using System;
2 using System.Collections.Generic;
3 using System.Text;
4 using Microsoft.Practices.CompositeUI;
5
6 namespace WindowsApplication1
7 {
8 public class Form1WorkItem : WorkItem
9 {
10 }
11 }
What we’ll do to CAB-enable the application is one more change. This is to the Program.cs file that is the main entry point for the application. Here’s the default one from Visual Studio:
1 using System;
2 using System.Collections.Generic;
3 using System.Windows.Forms;
4
5 namespace WindowsApplication1
6 {
7 static class Program
8 {
9 /// <summary>
10 /// The main entry point for the application.
11 /// </summary>
12 [STAThread]
13 static void Main()
14 {
15 Application.EnableVisualStyles();
16 Application.SetCompatibleTextRenderingDefault(false);
17 Application.Run(new Form1());
18 }
19 }
20 }
Nothing special here but we’re going to transform this by doing the following:
- Add Microsoft.Practices.CompositeUI.WinForms to the using statements of the file
- Change the Program class from static to public
- Inherit from the FormShellApplication class in CAB
- Modify the Main method to support CAB
Here’s the modified version of the Program class that supports the CAB (also note the change from static to public):
1 using System;
2 using System.Collections.Generic;
3 using System.Windows.Forms;
4 using Microsoft.Practices.CompositeUI.WinForms;
5
6 namespace WindowsApplication1
7 {
8 public class Program : FormShellApplication<Form1WorkItem, Form1>
9 {
10 /// <summary>
11 /// The main entry point for the application.
12 /// </summary>
13 [STAThread]
14 static void Main()
15 {
16 new Program().Run();
17 }
18 }
19 }
The only difference here is that we derive our application from FormShellApplication (a generic class in the CAB), passing the WorkItem class and the Form class we created. Also the startup in Main has changed to call the Program classes run (defined in the FormShellApplication class) rather than the standard Application.Run(). As we’re setting the value of the form in the FormShellApplication via generics so there’s no need for us to pass the Form class to the Application class like we did in regular .NET. There’s a nice blog entry here by Brad Wilson on describing the FormShellApplication class (and other classes in the CAB) which you might want to take a peek at.
That’s it. Build the solution (hopefully you shouldn’t have any errors) and run the app with F5 (or Ctrl+F5).
Amazing huh? This looks and behaves no different than a regular WinForm app but it’s now CAB enabled and almost ready to go. As I said, this is a super simple example and doesn’t even display “Hello World” or anything. With the tires kicked, we’re ready to start adding form and functionality the CAB way!
So what did we get out of this post? Hopefully you can see the (minor) differences between a regular Windows application and a CAB-enabled one (pretty simple huh?) and your project is now ready to start using features of the Composite UI Application Block. We’ll start exploring what you can do in the next entry in this series.
