Exploring .Net 3.0

.NET 3.5 and LINQ – Exploring C# 3.0

AppDomains and AddIn

AppDomains and Addins

What is an Application Domain (AD)?

An Application Domain is a CLR feature that provides a unit of isolation for an application. An AD may be thought of as a lighter weight process boundary. Multiple AppDomains may be created within a host process. The CLR also verifies that the user code in an App domain is type safe. An assembly must be loaded into an application domain before it can run (see default domain). By default, the CLR loads an assembly into the Application Domain containing the code that references it.

Default Domain

When a process that hosts the CLR is created, the CLR automatically creates a default App Domain. Note that there is one CLR per process. I will come back to this in future posts when speaking to versioning, Side by Side (SxS), LockCRL version, etc.. The default App Domain remains as long as the host process lives. The Host code will undoubtly need to live as long as the process, but Add-in’s (Assemblies loaded by the Host) should be isolated from the host code (see isolation).


An isolation boundary provides a level of protection between the Host assembly and the assemblies running in the AD(s). And of course, an Assembly in one AD is also isolated from an assembly loaded in another AD. An isolated assembly may not directly access code or resources in another assembly.

The life time of an Add-in(s) may not be as long as the life time of the host process. The Host should have control over the Add-in’s life time and via isolation the Host has the opportunity to control the temporal nature of Add-in’s. The host may also load multiple Add-in’s into the same App Domain (clumping) where they have like semantics, such as; shared security context, life times, shared resources, etc.. In the case of ASP.net this is the model. Imagine a server application that loaded transient code into its process but never had the ability to unload and therefore release resources. The resources consumed would never be reclaimed.


There is no ability within the CLR to unload an assembly (Why not?) at run time. The ability to unload an assembly is made possible via unloading an AppDomain and thus the assembly or assemblies within the AppDomain.


As a host, you must be conscience of the remoting boundary in your programming model. Since you are crossing an AppDomain boundary (just as you would when crossing a process boundary) your objects need to be MarshalByRef (MBRO) and instantiated via System.Runtime.Remoting. There is a brief discussion on this subject in JasonZ’s blog comments. Alternatively you could use serialization but you loose the reference semantics as you are making a copy. For a great write up on value and reference types follow this link.

There are versioning considerations you need to understand when communicating between components. The good news, is that we have the WinFX AddIn model libraries and forth coming guidance on design considerations to help you in this regard. I will be blogging more on this subject and maybe even co-authoring a book on the subject, if the demand is warranted (hint, hint – tell me if you would find this valuable).


Declaring assemblies to have domain-neutral behavior may be accomplished via the runtime hosting interfaces (see the framework SDK CorBindToRuntimeEx). Loading code that is domain neutral will improve performance on subsequent referencing of the same code in additional AppDomains, because the assembly code pages will be shared across the AppDomains.

So then the question arises as to why not load everything domain-neutral. The primary reason is that domain-neutral code may not be unloaded. So does this conflict with the Add-in model guidance of unloadability and isolation? No, the majority of the scenarios addressed by the Add-in model would not have Add-in’s loaded in the GAC, nor desired to be shared across AD’s. Common functionality offered by the hosting application to the Add-in’s, is a likely candidate for domain-neutrality as opposed to Add-in assembly neutrality. You may wish to reread that last sentence ;-). These classifications of Host provided assemblies are available to consumers (Add-in’s) for the duration of the Host process. So there should be no conflict in the Add-in model isolation and unloadability recommendation and domain-neutrality.

In v1.0 and v1.1 native images that Ngen.exe produces cannot be shared (domain-neutrality) across AD’s. In v2.0, native images that Ngen.exe produces can be shared (domain-neutrality) across AD’s.

AppDomainSetup Properties

There are additional properties to the ones I touch on below, but I wanted to call out two primary properties of interest.


The ApplicationBase is the root directory of the application. When an AppDomain is created, it inherits the ApplicationBase of the AppDomain creator (the Host in the Add-in model). When an assembly is loaded from disk, the CLR uses this root as the probing path. It is very likely that the Add-in will be installed in a different directory than the host application. In the majority of the cases, the two are installed and uninstalled independently of each other.


The optional configuration file, is an XML file, that has settings for the application. Most people are familiar with the concept when they think about machine.config. The configuration file can be used for declaring a startup shim, versioning rules, etc.. The configuration file will be something along the lines of MyApp.exe.config or MyApp.dll.config.


A host can control policy in two ways.
1. The host can provide evidence when creating the AD.
2. The host can restrict the permissions granted at a policy level.


It could be argued that this is a lot of work. However, the CLR and the framework, already simplify much of this for you. Of course, as the Host, you must hook up all the various functionality provided via the framework. The number of Hosts (ISV’s and large application providers) that need to provide this functionality is small in comparison to the number of customizations/applications/Add-in’s that will be written against a Host application. So the complexity, and thus the burden, is placed on a significantly fewer number of developers. And to further simplify the lives of ISV’s, which is my current job :-), we have the System.AddIn* offering.


PRISM (Composite WPF) is a project endorsed by Microsoft specifically targeted at WPF, and hosted on CodePlex. According to Glenn Block, a Technical Product Planner for Microsoft, PRISM offers the following benefits:
o Provides complete support for WPF
o Dynamically composes user interface components
o Application modules are developed, tested and deployed by separate teams
o Allows incremental adoption
o Provides an integrated user experience
Right now, PRISM “includes a reference implementation, a reusable library code and pattern guidance”, but the plan is to develop a framework which composite applications can be built upon.

The Microsoft Patterns & Practices Team created the Prism CodePlex Project. Prism is a set of assets for developing Composite WPF applications. Prism includes a reference implementation, reusable library code and pattern guidance. Using Prism enables designing a composite application that is composed of many discrete, loosely coupled modules.

Prism means
– Composite WPF
– Composite Application Guidance for WPF

Prism is a set of guidance coming out of Patterns and Practices for building composite applications in WPF.

Composite Application – It’s essentially an application that is dynamically composed from a set of different pieces

How different Prism is from CAB?

In one sense very different because Its not taking one line of code from CAB into Prism, so it’s a completely new effort. The reasoning for that is several fold: one reason is that WPF is entirely different than WinForms, completely different paradigm, the technology is different. There is a lot of things in CAB that have to reinvent the wheel because there was no similar construct in WinForms, but now actually things like commanding, for example, is build in to WPF. So for that reason plus combined with a large amount of feedback that microsoft p&p team got from customers who use Smart Client Software Factory which built on top of CAB and CAB, about how difficult it was to grok the number of abstractions, the fact that it was very imposing. I really had to accept every aspect of it which brought along a bunch of heaviness with it, and also it required me to build from scratch. So we’ve got costumers that are extremely happy with CAB and SCSF, but even the people that have been very happy have had a bunch of pains getting there, so we felt for that reason that we had a chance to both address delivering the right kind of guidance for the technology, being WPF, and at the same time to address the concerns that we heard from many customers

Components Mappings – CAB and PRISM

CAB Commands – Replaced with WPF Commands. See the Commanding Quick Start.
CAB EventTopics – See the IEventAggregator Service interface in the Events Quick Start.
CAB Items – Again replace with DI Container of your choice.
CAB Services – Service dependencies are resolved the DI Container similar to CAB.
CAB Smart Parts – Lots of options here – Any WPF User control can be a smart part or you can simply display a model with an associated DataTemplate (an approach I favor). Separated presentation parts are again wired through the DI container.
CAB State – Personally I never used this much in CAB, but you can resolve global state through the DI container if you wish.
CAB UIExtensionSites – with WPF’s flexibility a module can just add new items to a menu/toolbar without extra functionality. It could be a Comp WPF region.
CAB WorkItems – You can create you own hierarcy of containers, but Comp WPF seems to favor simply one container. What’s more important is to segment you business logic. See WorkItem controller below.
CAB Workspaces – Comp WPF uses regions and Region Manager Service. You can name regions in your XAML with an attached property.

PRISM Technical & Design Concepts.

Technical Concepts

1. Bootstrapper
– The bootstrapper is responsible for the initialization of an application built using the Composite Application Library. Having a bootstrapper gives you more control of how the Composite Application Library components are wired up to your application. For example, if you have an existing application that you are adding the Composite Application Library to, you can initialize the bootstrapping process after the application is already running.
In a traditional Windows Presentation Foundation (WPF) application, a startup Uniform Resource Identifier (URI) is specified in the App.xaml that launches the main window. In an application created with the Composite Application Library, it is the bootstrapper’s responsibility. This is because the shell relies on services, such as the Region Manager, that need to be registered before the shell can be displayed. Additionally, the shell may rely on other services that are injected into its constructor. For more information about the shell, see the Shell and View technical concept.

The Composite Application Library includes a default abstract UnityBootstrapper class that handles this initialization using the Unity container. Many of the methods on the UnityBootstrapper class are virtual methods. You should override these methods as appropriate in your own custom bootstrapper implementation. If you are using a container other than Unity, you should write your own container-specific bootstrapper.

2. Container and Services – The Composite Application Library is designed to support other dependency injection containers. Core services, such as the ModuleLoader service, are container agnostic. They use the Composite Application Library container or IContainerFacade interface for resolving, instead of directly accessing the containers. The Composite Application Library provides the UnityContainerAdapter, which is a Unity-specific implementation of this interface. This container is registered by the UnityBootstrapper.

3. Module – A module in the Composite Application Library is a logical unit in your application. Modules assist in implementing a Modularity design. These modules are defined in such a way that they can be discovered and loaded by the application at run time. Because modules are self-contained, they promote separation of concerns in your application. Modules can communicate with other modules and access services through various means. They reduce the friction of maintaining, adding, and removing system functionality. Modules also aid in testing and deployment.
4. Region – Conceptually, a region is a mechanism that developers can use to expose Windows Presentation Foundation (WPF) controls to the application as components that encapsulate a particular visual way of displaying and laying out views. Regions can be accessed by name and support adding or removing views. This decoupling allows the appearance and behavior (look and feel) of the application to evolve independently of the views that appear within the region (for more information about views, see the Shell and View technical concept).
Regions are intended to enable a compositional pattern and are commonly used in template layouts and multiple view layouts.
5. Shell and View – The shell is the main window of the application where the primary user interface (UI) content is contained. The shell may be composed of multiple windows if desired, but most commonly it is just a single main window that contains multiple views. The shell may contain named regions where modules can add views. It may also define certain top-level UI elements, such as the main menu and toolbar. The shell also defines the overall appearance and behavior (look and feel) for the application. It may define styles and borders that are present and visible in the shell layout itself, and it may also define styles, templates, and themes that get applied to the views that are plugged into the shell.
Views are the composite portions of the user interface that are contained in the shell’s window(s). It is easiest to think about a view as a user control that defines a rectangular portion of the client area in the main window. However, views in the Composite Application Library do not have to be defined with a user control. You can use a Windows Presentation Foundation (WPF) data template to define a view that will be rendered based on the data in your model. A view could also share screen real estate with other views due to the rendering and compositing capabilities of WPF. In simple terms, a view is just a collection of user interface elements that define part of the rendering of the user interface. It is a unit of encapsulation for defining the separable portions of your UI.
6. EventAggregator -The EventAggregator service is primarily a container for events that allow decoupling of publishers and subscribers so they can evolve independently. This decoupling is useful in modularized applications because new modules can be added that respond to events defined by the shell or, more likely, other modules.
In the Composite Application Library, EventAggregator allows subscribers or publishers to locate a specific EventBase. The event aggregator also allows for multiple publishers and multiple subscribers
7. Commands – Commands are a way to handle user interface (UI) actions. They are a loosely coupled way to bind the UI to the logic that performs the action.
When building composite applications, presentation design patterns such as Model-View-Presenter (MVP) and Model-View-Controller (MVC) are often used to separate the UI logic from the UI layout and presentation. When implementing these patterns with Windows Presentation Foundation (WPF), the presenter or controller handles commands but lives outside the logical tree. WPF-routed commands deliver command messages through UI elements in the tree, but the elements outside the tree will not receive these messages because they only bubble up or down from the focused element or an explicitly stated target element. Additionally, the WPF-routed commands require a command handler in the code behind.
The Composite Application Library introduces two new commands that can be routed outside the boundaries of the logical tree and that do not require handling logic in the code behind. The commands are custom implementations of the ICommand interface defined by WPF, and they implement their own routing mechanism to get the command messages delivered to objects outside of the logical tree. The commands in the Composite Application Library include DelegateCommand and CompositeCommand.
8. Communication – When building large complex applications, a common approach is to divide the functionality into discrete module assemblies. It is also desirable to minimize the use of static references between these modules. This allows the modules to be developed, tested, deployed, and updated independently and forces loosely coupled communication.
When communicating between modules, you can use commanding, event aggregation, or shared services. Use the following to help decide which approach to use:
• Commanding. Use this in response to user gestures and custom enablement.
• Event aggregator. Use this to publish an event across modules.
• Shared services. Use this if neither of the preceding is applicable

Design Concepts

1. UI Composition – Composite applications typically compose their user interfaces (UIs) from various loosely coupled visual components, otherwise known as views, to deliver an integrated application experience. To the user, the application appears as a seamless program that offers many capabilities
2. Modularity – Modularity is designing a system that is divided into a set of functional units (named modules) that can be composed into a larger application. A module represents a set of related concerns. It can include components, such as views or business logic, and pieces of infrastructure, such as services for logging or authenticating users. Modules are independent of one another but can communicate with each other in a loosely coupled fashion.
A composite application exhibits modularity. Imagine an online banking program. The user can access a variety of functions, such as transferring money between accounts, paying bills, and updating personal information from a single user interface (UI). However, behind the scenes, each of these functions is a discrete module. These modules communicate with each other and with back-end systems such as database servers. Application services integrate components within the different modules and handle the communication with the user. The user sees an integrated view that looks like a single application
3. Container – Applications based on the Composite Application Library are composites that potentially consist of many loosely coupled modules. They need to interact with the shell to contribute content and receive notifications based on user actions. Because they are loosely coupled, they need a way to interact and communicate with one another to deliver the required business functionality.
To tie together these various modules, applications based on the Composite Application Library rely on a dependency injection container. The container offers a collection of services. A service provides functionality to other modules in a loosely coupled way through an interface and is often a singleton. The container creates instances of components that have service dependencies. During the component’s creation, the container injects any dependencies that the component has requested into it. If those dependencies have not yet been created, the container creates and injects them first.
In some cases, the container itself is resolved as a dependency. For example, modules will often register views of the container by having the container injected.
There are several advantages of using a container:
• A container removes the need for a component to have to locate its dependencies or manage their lifetime.
• A container allows swapping the implementation of the dependencies without affecting the component.
• A container facilitates testability by allowing dependencies to be mocked.
• A container increases maintainability by allowing new services to be easily added to the system.
In the context of an application based on the Composite Application Library, there are specific advantages to a container:
• A container injects module dependencies into the module when it is loaded.
• A container is used for registering and resolving presenters and views.
• A container creates presenters and presentation models and injects the view.
• A container injects the composition services, such as the region manager and the event aggregator.
• A container is used for registering module-specific services, which are services that have module-specific functionality.


MAF (Managed AddIn Framework)

The Managed Add-in Framework defines a programming model, built on top of .NET that allows applications to dynamically load and communicate with generic components at runtime. We provide a solution for creating independently versioning, mutually distrustful components, and allow them to work together. We tackle the two problematic – versioning and isolation – together.

At PDC05, Thomas Quinn, an architect on our team, responsible for VSTO and VSTA, and Jim Miller, a CLR architect, responsible for several platform components related to versioning support in the CLR, among other things, jointly presented the platform framework for managed Addin’s. See the PDC FUN309 session.

What is an Add-In?

An add-in is traditionally thought of as custom code (a customization), written by a third party that is loaded and activated by a Host application (Word, Excel, etc…) upon the host starting up. The host makes their programmable API (Object Model) available to the customization assembly. In the case of the Office host applications, the Application object, which is the root of the hierarchical object model, is made available to the Add-in. I will use “Addin” in a more generic sense to mean code that is discovered based upon some event (The host Starting up, the loading of a document, etc..). Later, I will argue that this definition is too narrow.


Note that the definition I just articulated was a dynamic loading mechanism as opposed to static. An Addin is also generally loaded into the host’s process. This requirement then adds the concern of isolation. The host needs to be isolated from errant behavior of the Addin and Addin’s should in many cases, be isolated from each other. Although it is implied, the two components also need to agree on some communication protocol (a contract).

An Addin should be able to be loaded/unloaded of its own accord or loaded/unloaded by the host.
The requirement to Load/Unload Addin’s dynamically, adds the further requirement that the Host and Addin need to version independently.

A picture is worth a thousand words

Text image representation

Host Application – Adapter IContract | IContract – Proxy – Add-In

Host Process – Implements Contract IMyContra | ct : IContract – Addin Friendly facade/OM – Customization

<————————————-Direction of Call————————————————————–

Vertical bar (|) represents a boundary (Process, AppDomain)


Pre-defined interfaces used as explicit, agreed upon protocols for communication between two endpoints.

• All user defined contracts derive from IContract the base interface.
• A Contract is roughly analogous to a COM Interface.
• Possibly a better description from Thomas Quinn (aka TQ), “A Contract is any .NET interface, derived from IContract (to be defined), and having the following properties: it never versions beyond servicing, the containing assembly contains only other Contracts or non-versioning types, and it exposes in its method signatures only other Contracts, or fully known, loadable, and serializable type. It explicitly cannot contain the types System.Object, System.Type, System.MarshalByRefObject, any type from System.Reflection nor delegates or events, nor any other type which may cause the exposure of an implementation type”


• Implement contracts.
• Adapters serve the purpose of adapting between a friendly .NET Framework based programming model on each end and the less friendly, and more restricted contracts in the middle. Adapters are the object model.
• Similar in concept to web services. Although MAF is designed for Object Oriented services versus a Services Oriented model. We have worked with the Indigo team (aka. Windows Communications Foundation) on ensuring the two models are in alignment and they will continue to evolve in conjunction with each other. In a nutshell, both models prescribe an explicit understanding of boundaries (web service boundaries are machine), proxy generation, agreed upon contracts, separation of the definition and implementation and consumption, etc…


• Consume (call into) contracts.
• Exposes an object oriented, .NET Friendly surface to its consumers (Add-in’s).
• Similar in concept to consuming web services.
• Makes requests across the App Domain boundary.

.Net platform libraries

System.AddIn.dll and the System.AddIn namespace

• The NS will first be made available to the public in the VSTA/O12 release in the second half of 2006.
• The VSTA product and MAF have been announced at PDC 2005.
• First available in VSTA/O12 and then made available broadly in Orcas as part of the platform (CLR).
• This System.AddIn.dll is the Add-in loader
• An Add-in is any component that is discovered and loaded at runtime by a hosting application and that version separately from the hosting application. The loader is the component that is responsible for the App domain creation utilizing a customizable security manager, loads and activates Addin’s in specified App domains and provides Add-in unloading of specified App domains. The level of unloading in the CLR is by process or AppDomain.


• This dll may not version (first tenant of a contract).
• First available in VSTA/O12 and then made available broadly in Orcas as part of the platform (CLR),
• Defines base contract IContract
• Provides a remote kind of reflection. The contracts mimic the similarly named types in the System.Reflection namespace without providing the full implementation. The goal here is to be able to invoke methods and properties, set and get fields and handle events on objects across the remoting boundary without having direct access to that object’s Type. We provide a remote type surrogate that performs the duties of Type and its friends.


CAB WorkItem


1. A WorkItem is a class encapsulating logic for one dedicated use case.
2. It can be seen as a use case controller that knows all the different aspects of a use case.
3. A WorkItem holds state for all parts involved in a use case, such as views necessary to display, or sub-use cases.
4.It acts as an entry point into the use case (or one of its sub-use cases) it is responsible for.

POINT: A WorkItem can be composed of other nested WorkItems, each of which can have its own state. This state is analogous to ASP.NET session state.

POINT:You can use special persistence techniques to save WorkItems and then restore them later.

POINT:WorkItems are arranged in a tree-like chain, as shown on the facing page. The root work item, the base of the chain, is created by the shell application as part of its start-up process, as you saw in the preceding chapter. When modules are loaded into the process, they create work items and add them as children to the root work item’s chain.

WorkItem Details

The main purpose of a WorkItem today is to facilitate loose coupling by holding certain classes of objects in well-known locations so that other objects can find the resources that they need to do their jobs. To accomplish this, the WorkItem class contains a number of collections, as shown in Table 3-1. All of them are strongly typed except Items, which exists to hold anything not served by a strongly typed collection.

Property Name Description
——– ————————————–
Commands Command objects, used for tying .NET events from user interface objects such as menus to business logic methods.
EventTopics EventTopic objects, used in conjunction with CAB’s loosely coupled publish-and- subscribe event system (see Chapter 6).
Items All objects contained in this WorkItem that do not belong in any of the other collections, which are strongly typed. Web service proxies are a good example of the sort of thing that you often find here, as are WorkItem controllers.
Services CAB services
Smart Parts Smart Parts, which are objects with the SmartPart attribute applied to them, also known as views.
State State collection associated with this WorkItem.
UIExtensionSites UIExtensionSite objects, used for negotiating the content of shared user interface items such as menus and toolbars.
WorkItems Child WorkItems that belong to this WorkItem.
Workspaces Workspace objects, which are frames used for visual display of views.

Adding objects or Items in WorkItem


Objects are created and placed into the collections of a WorkItem in various ways. Sometimes this happens because of declarative attributes that are placed onto a class or a method
For example, the following code appears in the ShellForm class generated by the SCSF Wizard:


public void StatusUpdateHandler(object sender, EventArgs e)

The EventSubscription attribute, when processed by the CAB framework, tells the framework to find the EventTopic object whose name is StatusUpdate in the WorkItem causing the load, creating it if necessary, and to add this particular subscription to it. That EventTopic is created and added to the WorkItem collection the first time this attribute is encountered by the CAB framework processing.

WAY:2 By ObjectBuilder

Other types of objects are added to WorkItems transparently when the CAB object builder creates them. In the ShellForm created by the SCSF, the object builder notes when it is creating the shell form that some of the child controls on the main form are Workspaces and not just plain windows. After creating them, the object builder places them into the root work item’s Workspaces collection.

WAY:3 By calling the AddNew method

Fetch an item from a WorkItem

To fetch an item from a WorkItem collection to use it, you usually use the Get method. When using the Services collection, as you saw in the preceding lesson, you specify the interface for which you want the implementing service, thus:

private void AuthenticateUser()
// Fetch the authentication service from the root work item,
// and call the method to make it authenticate the user.
IAuthenticationService auth =rootWorkItem.Services.Get(true);

The objects in the other collections are designated by string names. You fetch the desired item by indexing the collection with the string name, thus:

// User clicked this button. Look at event topic and
// fire it programmatically.
private void toolStripButton3_Click(object sender, EventArgs e)
EventTopic et =_rootWorkItem.EventTopics[EventTopicNames.StatusUpdate] ;
if (et != null)
et.Fire(this, new EventArgs(“Fired programmatically”),_rootWorkItem, PublicationScope.Global );

Disposing WorkItem

The WorkItem class provides this capability by implementing the IDisposable interface. If you call Dispose on a WorkItem, it iterates through all its collections and calls Dispose on every item that supports that interface. In the CabApplication class startup code, for example, the Run method calls Dispose on the root WorkItem to clean it up as the application is terminating

Composite UI Application Block (CAB)

The Composite UI Application Block is a ready-to-use building block provided by the Microsoft patterns & practices group for creating complex, modularized smart client applications. This building block basically provides the following functionality:
1 Dynamically loading independent yet cooperating modules into a common shell
2 Event broker for loosely coupled communication between modules and parts of modules
3 Ready-to-use Command pattern implementation
4 Base classes for Model-View-Control (MVC) pattern implementations
5 Framework for pluggable infrastructure services ranging, such as authentication services, authorization services, module location, and module loading services

CAB is built for designing applications based on a use case¡Vdriven approach by clearly separating use case controller classes from views with their controller classes or presenter classes. Central client-side services can be added through the services infrastructure provided by CAB.

Major terms related to CAB that are important for architectural decisions.

A WorkItem is a class encapsulating logic for one dedicated use case. It can be seen as a use case controller that knows all the different aspects of a use case. As such, a WorkItem holds state for all parts involved in a use case, such as views necessary to display, or sub-use cases. Furthermore, it acts as an entry point into the use case (or one of its sub-use cases) it is responsible for.

Services encapsulate functionality that is common for the whole client application, for a specific module, or just for WorkItems within a certain hierarchy of WorkItems (for example, for sub-WorkItems of a specific parent WorkItem). Typical services are security services responsible for authentication or authorization or Web service agents encapsulating service communication and offline capability.

Multiple, logically related WorkItems can be summarized into a single unit of deployment. A module is an example of a unit of deployment. Configuration of CAB-based smart clients basically works on a module-level. Therefore, finding the right granularity for encapsulating WorkItems into modules is crucial.

The profile catalog is just a configuration that specifies which modules and services need to be loaded into the application. By default, the catalog is just an XML file that resides in the application directory. This XML file specifies which modules need to be loaded. By writing and registering a custom IModuleEnumerator class, you can override this behavior to get the catalog from another location, such as a Web service.

This is a general service provided by CAB, which is responsible for loading all the modules specified in a profile catalog. It just walks through the configuration of the profile catalog, tries to dynamically load the assembly specified in a catalog entry, and then tries to find a ModuleInit class within that assembly.

Each module consists of a ModuleInit class, which is responsible for loading all the services and WorkItems of a module.

Shell application
The Shell application is the primary application that is responsible for initializing the application. It is responsible for dynamically loading modules based on the configuration and launching the base services for the smart client application, in addition to starting the main form (Shell).

This is the main form of the application; it provides the user interface that is common to all dynamically loaded modules. The Shell always hosts the root WorkItem, which is the entry point into any other parts of the application, such as services, modules, and WorkItems that are created and registered by these modules.

A workspace is a control that is primarily responsible for holding and displaying user interface elements created by WorkItems. Usually workspaces are added to the Shell (or to other extensible views within your WorkItem hierarchy) and act as containers for parts of the UI that are going to be dynamically filled with UI items that are provided by WorkItems or sub-WorkItems. Any user control can be a workspace by implementing the IWorkspace interface. Out-of-the-box, CAB includes classic container controls as workspaces, such as a tabbed workspace.

UIExtensionSites are special placeholders for extending fixed parts of the Shell such as menus, tool strips or status strips. Unlike workspaces, they are intended to be used for parts of the UI, which should not be completely overridden by WorkItems; instead, they should just be extended (such as adding a new menu entry).

Command is a base class of CAB for implementing the Command pattern. CAB supports classic commands created manually or declarative commands by applying the [CommandHandler] attributes to the method; these attributes act as command handlers. You can register multiple invokers for one command

EventPublications are used by event publishers for loosely coupled events. An event publisher implements the event through .NET Framework events that are marked with the [EventPublication] attribute. Events are uniquely identified by event URIs (unique strings). Only subscribers using subscriptions with the same event URI will be notified by CAB. A subscriber needs to have a method with the same signature as the event used [EventPublication] and needs to be marked with the [EventSubscription] attribute.

EventSubscription is the opposite of EventPublication. Any class that wants to subscribe to an event with a specific event URI needs to implement an event handler that matches the method signature of the EventPublication. You must mark this event handler with the [EventSubscription] attribute and the publisher’s event URI (in the attribute’s constructor) and CAB makes sure that a subscriber will be notified each time a publisher raises an event with a matching event URI and method signature.

Model is the (client-side) business entity a WorkItem processes; for example, Customer, BankAccount, or Loan.

View is an ordinary .NET Framework user control that is responsible for presenting a part of or the whole model to the user and allowing the user to modify its contents through user interface controls. Typically, the view implements only UI logic; whereas the related client-business logic is implemented in the presenter/controller.

A SmartPart is a .NET Framework user control with the [SmartPart] attribute applied. Optionally, a SmartPart can implement the ISmartPartInfoProvider interface. As such, it provides additional information about itself, such as a caption or a description.

Controller is a class that implements the logic for modifying a model. One controller can modify a model presented by many views. Origin: Model-View-Controller

ObjectBuilder is a foundation component of CAB that acts as the factory for creating objects that require specific builder strategies to be created or that need features, such as automatic instantiation and initialization of dependant objects when creating instances. As such, the ObjectBuilder has a combined role as a factory, a dependency injection framework, and a builder strategy framework.

Dependency Injection
Dependency Injection is a pattern that allows a factory to automatically create or initialize properties or members of objects with dependant objects. ObjectBuilder provides this functionality.

A WorkItemController is a class introduced by the Smart Client Software Factory that encapsulates common initialization logic for a WorkItem. When creating WorkItems with SCSF, instead of directly inheriting from the WorkItem base class, you inherit from this class to get the added initialization logic.

Again, this is a class introduced by the Smart Client Software Factory; it is a generic class for instantiating new WorkItems based on a WorkItemController. It launches the added initialization entry points provided by the WorkItemController for you.

ModuleController classes are introduced by the Smart Client Software Factory and are used for encapsulating a special WorkItem within a module taking on the role of a root WorkItem within a module. The default ModuleInit implementation of a module created with the Smart Client Software Factory automatically creates a WorkItem for a module named ModuleController. Therefore, the ModuleController is the primary entry point for all WorkItems provided by a module.

Presenter is a class that implements the logic for one single
SmartPart (view). The presenter is based on the Model-View-Presenter (MVP) pattern, which is basically a simplified variant of the Model-View-Controller (MVC) pattern. The big difference between MVP and MVC is that with MVP, the View is completely controlled by the presenter, whereas in the MVC, the controller and the model can update the view.

Happy Coding…:)

What is the difference between abstract class and interface?

If a class is to serve the purpose of providing common fields and members to all subclasses, we create an Abstract class. For creating an abstract class, we make use of the abstract keyword. Such a class cannot be instantiated. Syntax below:

abstract public class Vehicle { }

Above, an abstract class named Vehicle has been defined. We may use the fields, properties and member functions defined within this abstract class to create child classes like Car, Truck, Bike etc. that inherit the features defined within the abstract class. To prevent directly creating an instance of the class Vehicle, we make use of the abstract keyword. To use the definitions defined in the abstract class, the child class inherits from the abstract class, and then instances of the Child class may be easily created.
Further, we may define abstract methods within an abstract class (analogous to C++ pure virtual functions) when we wish to define a method that does not have any default implementation. Its then in the hands of the descendant class to provide the details of the method. There may be any number of abstract methods in an abstract class. We define an abstract method using the abstract keyword. If we do not use the abstract keyword, and use the virtual keyword instead, we may provide an implementation of the method that can be used by the child class, but this is not an abstract method.
Remember, abstract class can have an abstract method, that does not have any implementation, for which we use the abstract keyword, OR the abstract class may have a virtual method, that can have an implementation, and can be overriden in the child class as well, using the override keyword. Read example below

Example: Abstract Class with Abstract method
namespace Automobiles
public abstract class Vehicle
public abstract void Speed() //No Implementation here, only definition

Example: Abstract Class with Virtual method
namespace Automobiles
public abstract class Vehicle
public virtual void Speed() //Can have an implementation, that may be overriden in child class


Public class Car : Vehicle
Public override void Speed()
//Here, we override whatever implementation is there in the abstract class
//Child class implementation of the method Speed()

An Interface is a collection of semantically related abstract members. An interface expresses through the members it defines, the behaviors that a class needs to support. An interface is defined using the keyword interface. The members defined in an interface contain only definition, no implementation. The members of an interface are all public by default, any other access specifier cannot be used. See code below:

Public interface IVehicle //As a convention, an interface is prefixed by letter I
Boolean HasFourWheels()

Difference between Abstract Class and Interface

1) A class may inherit only one abstract class, but may implement multiple number of Interfaces. Say a class named Car needs to inherit some basic features of a vehicle, it may inherit from an Aabstract class named Vehicle. A car may be of any kind, it may be a vintage car, a sedan, a coupe, or a racing car. For these kind of requirements, say a car needs to have only two seats (means it is a coupe), then the class Car needs to implement a member field from an interface, that we make, say ICoupe.
2) Members of an abstract class may have any access modifier, but members of an interface are public by default, and cant have any other access modifier.
3) Abstract class methods may OR may not have an implementation, while methods in an Interface only have a definition, no implementation.

Happy Coding….!!!

Ref: http://www.dotnetuncle.com