Support for Split Assemblies in WPF Targets

The WPF Target provides the means to generate multiple assemblies from a build – one EXE and one or more DLLs – instead of a single EXE.

The Project painter has two additional tabs: Assemblies and Dependencies.

Use the Assemblies tab to determine what assemblies should be built from the target's PBLs. For each PBL in the WPF Target library list, you can select an output assembly. The drop-down lists in the second column of the list view contain all the PBL names with ".DLL" appended. Selecting an assembly name in the second column indicates that the PBL will be included in an output assembly of that name. More than one PBL from the left column can be built to the same output assembly by selecting the same output name. Leaving the second column value blank indicates the PBL will be built to the executable. You can also type a name in the second column. The name is added to all drop-down lists, allowing multiple PBLs to be built to the same output assembly of the given name.

The read-only Dependencies tab indicates how the output assemblies depend on one another to determine build order. You can update the page by running the dependency checker.

The Dependency Check

Detailed dependencies information is available in the Assembly Dependencies tool window after completing a full dependency check process. The dependency check process can be triggered:
  • manually from the menu Design > Check Dependencies or the WPF project object’s context menu, or
  • automatically by a full build process after changing the settings of the output assemblies.

All dependency errors indicated in the output window need to be solved before doing a full build for the target.

To solve dependency errors (dependency on executable or circular dependency), you can try the following methods.

  1. Combine the PBLs that have dependency errors into one output assembly.
  2. Move the objects from one PBL to another PBL.
  3. Build global variables into an output assembly if they are heavily used in different objects and different PBLs.
  4. Refactor the code to use another object; for example, use local or instance variables instead of global variables.
  5. Move heavily used objects from many different PBLs into a new PBL and then build to a single output assembly.
  6. Solve dependency errors on global external functions by using local external functions instead. This is due to a current limitation.