This post originated from an RSS feed registered with .NET Buzz by Brad Wilson. Original Post: CAB, June to October: Goodbye, ApplicationHost! Feed Title: The .NET Guy Feed URL: /error.aspx?aspxerrorpath=/dotnetguy/Rss.aspx Feed Description: A personal blog about technology in general, .NET in specific, and when all else fails, the real world. Latest .NET Buzz Posts Latest .NET Buzz Posts by Brad Wilson Latest Posts From The .NET Guy

This post discusses changes to the Composite UI Application Block as of the October 2005 CTP release.

Two pieces of feedback we got pretty consistently were:

• What is ApplicationHost? Why is it different from a WorkItem?
• Why can't I control the root WorkItemType in the application host?

We took both of these items to heart, and re-worked the root of the application hierarchy in CAB to make writing CAB applications easier and quicker.

We eliminated the ApplicationHost class and all the associated initializers. We replaced this with CabApplication<> and family, from which your main application file can now derive. Stage 1 of the Walkthrough (see the PDF in the Help directory for more information) has you creating the core of a CAB applicaiton: the Application and the Shell. You can see the application class as:

public class ShellApplication : FormShellApplication<ShellWorkItem, ShellForm>
{
   [STAThread]
   static void Main()
   {
     new ShellApplication().Run();
   }
}

You create an application class, which implements the Main entry point, and derives from one of our application classes. As generics, you pass the type of your root work item and the type of your shell, and the application class will automatically create both for you. This has greatly simplified and clarified the startup of an application.

You can see in this example we used FormShellApplication as our base class. In another post, I'll talk about our application classes and what they're for.