CAB and SCSF – Part1: Introduction (with example)

For the last couple of years I hearing about CAB and Smart Client Software Factory projects, but until recently I never had a chance to play with them. Now this is the time to change that, partly because I hate to have gaps in education, but mostly because now it is very relevant for the work I doing for living. I am planning to write series of the articles on this subject, from the design considerations to actual implementation. In this one I introduce CAB and SCSF, cover some basics and finally create “hello world” CAB application.

CAB (which is stands for Composite Application Block) is part of the Microsoft Enterprise Library. The best description I can do for it, is: CAB is kind of generic client. For example, let say we want create addin for Visual Studio. Our addin is completely separated dll, which can be activated or not. But when we plugging it into the VS, we want our tab will be added to VS tabs, toolbar buttons will be added to main toolbar, and our menu items will be added to the main menu. We want in our dll (module) use all services that VS provides, and when someone clicks our menu item in the main menu, we want to catch click event inside our module and handle it somehow. Trust me, from my own experience – doing such a framework from a scratch and doing it right is not trivial task at all.
That is exactly what CAB is doing. When you creating an application using CAB, it composed from different modules and each module can have different views, services, buttons and menus – but end user can never notice that. CAB can host WPF views. Also it provides all sources, so debugging is not the problem. And the most important thing: it’s free. Officially it has to run on VS 2005, but there is a way to run it on VS2008 – information here. I didn’t succeed to run it on VS2008 Express version. In the next few months expected release of fully WPF CAB version.
The possibilities here are endless. For instance, you can create some base application, and allow to third parties develop addins for it (VS is one example for such an application). Or maybe you want to have ability to add or remove some functionality in your application, according to customer’s license/demand. Other situation is where you have number of different applications and you want to compose them together to one main application.
From architecture view point, it is very comfortable way to develop application: it can be easily extended and modified. It well structured. Developers can concentrate on development of each module like it stand alone application, without knowledge about any other modules. And deployment and versioning is very easy task – just add or change dlls you need. By the way, CAB supports click-once deployment technology.
Now you can ask: ok, I got what the CAB is. But this article named “CAB and SCSF”. What is SCSF? And what its relationship to the CAB? The answer is that SCSF using CAB to build initial solution and makes it easy adding new CAB modules. You can consider SCSF as collection of wizards, to make your life a bit easier. For example, when you adding new CAB module you need to register it in the ProfileCatalog.xml (I will talk about it), register WorkItem and to do couple other registrations. SCSF provides nice wizards to do all that for you. It generates necessary code, initial shell and it even creates method stubs, which you most likely will want to implement.
There are very much I can write about CAB architecture, but due to lack of spare time, better download documentation about it from here – they have nice pictures also. The basic idea is that application has a base shell and then developers creating modules, which will hook views, buttons and menus on it. CAB provides EventBroker service, which provides ability to communicate between modules, without coupling between them. Each module has a WorkItem, and the whole application is a tree of WorkItems. Menus and toolbars which is meant to be populated by items from other modules, called “UIExtensionSites”, and should be registered properly.
In example I provide here, I created 3 different stand alone modules (first I created new Smart Client Application (C#), then using SCSF wizard added 3 business modules to the solution). You can open and observe ProfileCatalog.xml file – it contains registrations of each module.

First module has view (user control, which is also added using wizard), and that view contains tree view control. Each time selected node in the tree, fired event with the text of the selected item. Second module has simple label. This module subscribing to events from first module (without actually knowing it), and changing label text according to text from received event. Last module adds Help\About menu item to the main menu. When item is clicked, fired event is catch, and about dialog is displayed.

Points of interest:
This is how I declaring my event, when node in tree view is selected:

//declaration of “TextChanged” event
[EventPublication("event://TextChanged", PublicationScope.Global)]
public event EventHandler TextChanged;

Notice ‘ PublicationScope.Global’ – this mean every module can see my event.

This is how second module subscribes to that event:

[EventSubscription("event://TextChanged", Thread = ThreadOption.UserInterface)]
public void OnTextChanged(object sender, EventArgs args)
{
textLabel.Text = args.Data;
}

Thread option saying, that event should be received in UI thread. It can be caller or background threads. Nice!

This is how I adding menu item to the main menu, and registering to click event (this is kind of Command Design Pattern):
//create menu items and add them to main menu.
ToolStripMenuItem helpMenu = new ToolStripMenuItem(“Help”);
ToolStripMenuItem aboutItem = new ToolStripMenuItem(“About”);
helpMenu.DropDownItems.Add(aboutItem);

WorkItem.UIExtensionSites[UIExtensionSiteNames.MainMenu].Add(helpMenu);

//register to ‘Click’ event of the about menu item.
WorkItem.Commands["AboutCommand"].AddInvoker(aboutItem, “Click”);

And here I handling click event:

[CommandHandler("AboutCommand")]
public void ShowCustomerHandler(object sender, EventArgs e)
{
AboutDialog aboutDialog = new AboutDialog();
aboutDialog.ShowDialog();
}

Conclusion: for the first look, this framework promises very much and looks good. However, for me is too early to make final decision. How high performance of this thing? Is it adaptive to changes? Is it forcing me to some specific way of programming? I will try to answer these questions in the near future.