Chapter 2. B Generating a CAB Project with SCSF

B. Generating a CAB Project with SCSF

1. The SCSF contains a wizard for generating the projects that comprise a CAB application. After installing the SCSF and its associated utilities, you see the Guidance Packages item in the New Project dialog box in Visual Studio. The Smart Client Development item underneath it contains a template named Smart Client Application, as shown in Figure 2-1.

    

   Figure 2-1. Visual Studio template for generating Smart Client Application.

   [View full size image]

2. The SCSF needs to know the location of the CAB dynamic linked libraries (DLLs) and of the Enterprise Library DLLs because it uses both in its generated code. It prompts you for them using the box shown in Figure 2-2. You also need to enter the namespace to be used for the classes in your generated project.

    

   Figure 2-2. Wizard choices for generating Smart Client application.

   [View full size image]

   Note

    

   

   Not all SCSF project developers like using the Enterprise Library in their CAB programs. You can actually remove it quite easily from the code generated by the SCSF if you want. Just open each generated project and remove the references to the Enterprise Library DLLs. Then compile the code and see where the errors are. There are only about three locations in which you'll have to remove EntLib code, generally relating to exception handling. Just make sure you put in your own exception handling in its place and don't just leave it undone.

   
   

3. The SCSF generates four or five projects containing many files for a complete CAB application. Figure 2-3 shows the Visual Studio Solution Explorer displaying the results of such a generation. I will now discuss the purpose of each of the projects that you see.

   Figure 2-3. Projects generated by SCSF.

   

   The Shell project, as we've seen, is the main outer container of the application. It contains classes for the shell application and the shell form. It also contains the app.config file used by most .NET applications, and a ProfileCatalog.xml file used by the default module enumerator service, which we meet later in this chapter.

   The Infrastructure.Module project builds a DLL that is loaded by the module loader service when the project starts up. It creates a child WorkItem, which it adds to the WorkItem chain. Most CAB applications contain several modules that can create a WorkItem, so one of the reasons that the wizard generates this module is to demonstrate how it's done. A production application would probably use an infrastructure module to contain its own services and other resources rather than clutter up the shell project with them.
   Module项目编译了一个DLL，当这个项目启动的时候通过Module Loader Service加载这个DLL。它生成了一个子的WorkItem加入WorkItemChain中。大部分CAB Application都包含了几个Module，他们都能生成WorkItem。所以向导生成这个Module的原因是说明Module如何运行的。 一个生产的Application应该使用一个infrastructure module来包含自己的服务和其他资源，而不是和Shell Project放在一起。
   
   The Infrastructure.Library project contains the implementation of services that the SCSF adds to a CAB project. The action catalog service, which I discuss in Chapter 7, is an example of this sort of service. This DLL is generally deployed with the shell project and managed by the infrastructure team.
   
   Libray项目包含了SCSF添加到CAB中的服务实现。Action Catglog Service，7章有个这个Service的例子。这个DLL一般和Shell项目一起部署，并由infrastructure team 管理。
   
   The Infrastructure.Interface project contains the definitions of service interfaces, as distinct from their implementations. For example, it contains the definition of the IActionCatalogService interface, which is implemented in the Infrastructure.Library project I mentioned in the preceding paragraph. It also contains the implementation of certain core classes that we want all projects to use, such as ControlledWorkItem. In this sense, you might consider it a part of CAB 1.1. It also contains the definitions of string constants used for indexing many of the WorkItem chain's collections. This centralizing of string names avoids bugs and collisions later. You distribute this DLL to all development teams in the CAB project. This is the one piece of code that the developers actually do share, so you want it to be as sparse and as generic as possible—hence the inclusion of interface definitions rather than class implementations.
   
   Interface项目包含了Service Interface的定义，和它们的实现区别开来。例如，他包含了IActionCatalogService 接口的定义，这个接口在Library项目中实现。他也包括了我们想所有项目都使用的核心类，例如ControledWorkItem。他也包括了一些字符串的常量定义，用来索引WorkItem Chain集合。这个集中字符串名字的做法避免了错误和冲突。你分发这个DLL给所有开发团队。这是开发者真正共享的一部分代码，所以尽量使他松散和一般化，因此包括了接口的定义而不是类的实现。
   
   The Infrastructure.Layout project is generated when you select the Create a Separate Module to Define the Layout for the Shell check box in the SCSF Wizard. If you don't select this box, then the layout of the user interface will then live directly in the shell project. The Infrastructure.Layout project will not be generated, and the shell form will contain a menu, status bar, toolbar, and two workspaces. If you do select the box, then the shell form will contain only one workspace that covers its entire surface. The Infrastructure.Layout DLL will contain a Smart Part (also known as a view) called the Layout View. This view will contain all the UI elements that the shell previously had and automatically place itself into the shell's workspace at startup time. You make this choice when you need several different shell form layouts for different configurations of the program. For example, suppose that client A wants its customer selection on the left side of the shell form, but client B wants its customer selection on the top of the shell form. The loose coupling mechanism of CAB allows you to create two or more separate Infrastructure.Layout modules and load one or another at runtime according to configuration files. This allows you to separate layout and program implementation, with a great increase in program flexibility. If, on the other hand, you are a corporate developer building a program solely for in-house use, you might not want to take the trouble of separating these concerns.
   
   LayOut Project，在向导中选择单独生成才会有。否则，用户接口的layout将和shell 项目在一起，shell form将包括仅有一个workspace。 LayoutDll包括一个Smart Part，被称作Layout View。这个View包括所有的UI elements. 你可以有多个Layout，可以在运行时加载其中的一个。