Packaging The Application
For all practical purposes, packaging an OpenDCL application for deployment is no different than packaging any AutoLISP application for deployment. Most developers choose to convert their AutoLISP files into fast loading lisp (.fas) or compiled and packaged lisp (.vlx) files before deploying them to end users, however this may not be necessary or desirable for in-house applications.
When preparing AutoLISP files for deployment, it is important to include all dependent files, such as OpenDCL project files, data files, and utility files. It is also important to write code that does not use hard coded file paths, so that the application works correctly no matter where it is installed.
A common approach to handling loading of dependent files without requiring a hard coded path is to add the application's installation folder to the AutoCAD support path. However, this approach is risky because it can result in failure if the application path is accidentally removed from the AutoCAD support path, or if the support path exceeds its allowable length. A more robust solution is to write the installation path to the application's registry key, then prefix the saved path to the file name of the desired file at runtime.
Many developers want to package their OpenDCL project files so that end users or third parties cannot easily view or change their contents. The standard approach of packaging .odcl files separately from the associated AutoLISP files makes this impossible. OpenDCL provides a solution to this problem by allowing OpenDCL project data to be included directly inside the AutoLISP code as data, thus enabling the files to be compiled into a single .vlx that includes both the AutoLISP code and the OpenDCL project data. Embedding project data requires that an OpenDCL project be saved from OpenDCL Studio with an .lsp file extension. Manually typing a destination file name with the .lsp extension causes OpenDCL Studio to save the file in an encoded plain text format so that its contents can be copied and pasted directly into lisp code, then loaded by using the (dcl-Project-Import) function.
Including OpenDCL Runtime
OpenDCL applications must be deployed along with the OpenDCL Runtime. To ensure interoperability among multiple OpenDCL applications on the end user system, the OpenDCL runtime must be installed via Windows Installer. One way this can be accomplished is by distributing the OpenDCL Runtime .MSI file with the application, and executing the standalone .MSI file as a preliminary step in the application's installation sequence. Better yet is to merge the OpenDCL Runtime install directly into the application's installer by importing the OpenDCl Runtime merge module (.MSM) into the application installer script. Support for merge modules varies depending on the installer technology being used; if merge modules are not supported, or not supported fully, it may not be possible to use the merge module approach.
Either method for deploying OpenDCL Runtime ensures that the OpenDCL files are properly reference counted, so that uninstalling one OpenDCL application leaves the runtime files installed if any OpenDCL application still needs them, and removes the files when they are no longer needed.