InstallShield 11 Universal
Collaboration is the collection of capabilities and features that supports multideveloper environments by enabling large projects to be broken up into smaller pieces and worked on by several developers. The concept of an assembly is central to collaboration. An assembly is a self-contained, reusable, versionable, self-describing set of managed changes to a target system. A product is a commercial software product that can be installed by itself. An assembly must be installed by a product to be installed. Once installed, the assembly can be referenced and used by other products that are installed on the same machine. When referenced or installed by a product, an assembly can be associated with the features of the product so that the end user can choose to install it. Assemblies can also be associated directly with the product so that they are always installed, regardless of which features the end user chooses to install.
The term "assembly" does not refer to nor have any connection with Microsoft® .NET (".NET Assemblies") or other Microsoft® technology.
One of the benefits of creating and using assemblies is that they can be shared across different products. For example, several products that are installed on the same machine may require the same assembly, which is only installed once on that machine. The assembly remains installed on that machine until all of the products that require it have been uninstalled—it is uninstalled along with the last product that required it.
Another benefit of using collaboration is that different developers can work on product and assembly projects at the same time. Whenever an assembly is referenced by a product, it is considered to be a "required" assembly. Changes made to the product or its required assemblies are automatically included in nightly builds of the product because the assembly is dynamically bound to all of the products that reference it.
Versions of assemblies are backward compatible. For example, let's say that a product specifies that it requires version 1.0 of an assembly. When the product is installed, version 1.2 of that assembly is found to already be installed on the target machine (by locating its UUID that is registered in the VPD). The product will consider the assembly to already be installed and will reference version 1.2. If a new version of an assembly is created that is not backward compatible, however, then it should be given a new UUID.
The illustration below is a Human Resources scenario. There is one software package that accesses the employee database of names and addresses, and this software is developed and maintained by one developer. There are several other developers that develop and maintain the software for the Payroll System, the Benefits System, and the Scheduling System. The Employee Database access software is the shared, required assembly that is referenced by the Payroll, Benefits, and Scheduling System products, but the Employee Database access software is installed only once on the target machine by any of the three products. The installation location of the Employee Database access software is communicated by its developer to the developers of the other software so that, once the other software packages are installed, they can locate and utilize the Employee Database software. If, for example, the Scheduling and Benefits software are uninstalled, the Employee Database access software would remain installed on the machine because it is still required by the Payroll System.
This concept enables installation authoring in multideveloper environments. One group of developers creates the assembly projects, while another group of developers creates the projects that require those assemblies. Using the example above, if developer A makes a change to the Employee Database assembly project and developer B makes a change to the Payroll System product project, a nightly build of the Payroll System project would incorporate the changes made by both developers because the assembly is referenced by a feature in the Payroll System project.
An assembly can either be "global" or "location-specific" on the target machine. A location-specific assembly is an assembly that supports side-by-side installation, also known as "multi-instance assemblies." In other words, more than one copy of the assembly can be installed side-by-side on the same target machine. This contrasts with a global assembly which is a singleton on the target system—only one copy can be installed.
The "location-specific" concept is included in the assembly architecture for the single purpose of supporting side-by-side products and Dynamic Suites. The side-by-side nature of an assembly must be taken in the context of a product or suite that also supports side-by-side installation. Using the example of the Human Resources scenario above, if the Human Resources suite of applications supports side-by-side installation, then the assemblies can optionally be configured likewise (see Setting Existing Assembly Properties/Location property). Therefore, two installed instances of the Human Resources suite could either share a single database (a "global" assembly), or each have their own copy of the database (a side-by-side "location-specific" assembly).
Within a single product or suite, however, all assemblies are essentially "global"—there are no "side-by-side" distinctions. For example, the Human Resources Dynamic Suite gets only one database, whether that database is actually global (shared with other Human Resources suites) or private (owned by just this suite). Either way, from the suite's point of view, there is only one instance of that assembly (the database).
Universal does not support multiple side-by-side installs of a single assembly within a single product or suite. It is an error condition at both build and run times for a single product or Dynamic Suite to require a specific assembly in more than one location on the target system.
See Also
Assemblies vs. Merge Modules
Assemblies vs. Suites
Working With Assemblies