Deploying an application that uses the automation server
When deploying your objects, you need to coordinate registry
entries with the locations of all the files.
PowerBuilder runtime files
For both PowerBuilder.Application and a registered user object
as a server, you need to deploy the PowerBuilder runtime environment
on each user’s machine.
For information about PowerBuilder deployment
and required files, see Part 9, “Deployment Techniques.”
Instead of the PowerBuilder executable, the registry looks
for the PowerBuilder virtual machine DLL, PBVM110.DLL,
to start the runtime environment. When you deploy, the path for
this file is recorded in the registry. Users should not move the
file to another directory—the registry entry would be made
invalid.
Object library and type library
The registry records the location of the library containing
your object and the location of the type library.
Therefore, when you generate a registry update file on your
own computer, path information reflects the file location on your
machine. When you deploy, you can:
- Customize the registry update file (it is an editable text
file) - Make changes to the registry after it has been updated
You do this programmatically using functions in PowerBuilder
or the Windows SDK, or manually with the Registry Editor.
Multiple versions and updates
When you distribute a new version of an object, you can reuse
the GUID that was the CLSID for the previous version, or you can
assign a new GUID. Your choice should depend on the degree of compatibility
between the versions.
| Option for the CLSID | Conditions |
|---|---|
| Reuse the GUID | The interface for the object is the same and existing applications can access the same properties and functions that were in the old version |
| Assign a new GUID | The interface has changed and existing applications will fail if they access the new version |
If you assign a new GUID so that the old object remains available
to existing applications, you need a new ProgID too. If the existing
application refers to the version-independent ProgID and you use
the same ProgID for the new version, the old application will connect
to the new object anyway.
When you design your server object, you need to think about
its future development and design current applications accordingly.