Echelon LNS Plug-in - Manual (Page 30)

Redistributing your Plug-in
After you have developed and tested your plug-in, you can create an installation project for it so that
you can distribute your application to your users. See the documentation for your selected installer for
details on how to do this.
You should adhere to the following guidelines when creating an LNS plug-in installer based on the
framework:
• A plug-in based on the LNS Plug-in Framework requires Microsoft .NET Framework 2.0 (or
newer) to be installed. You can either embed the .NET Framework 2.0 within your plug-in
installation, or you can inform your users that but that they must have NET Framework 2.0
installed on their computers. Note that embedding .NET Framework 2.0 within your plug-in adds
40MB to the size of the installation, which may eliminate the possibility for some users to
download your plug-in over the Internet.
• Add the two merge modules provided with the LNS Plug-in Framework Developer’s Kit to your
installation to provide the LNS Interop and LNS Plug-in Framework assemblies. These merge
modules will always install to the Windows Global Assembly Cache to provide global access to
the assemblies. Note that changing the installation location of these assemblies does not modify
the target directory. If your plug-in needs to support LNS 3.23 or later, and not LNS 3.22, you do
not need to include the LNS Interop merge module because it is included in LNS 3.23 and higher.
• Register the plug-in with LNS and COM on installation, and unregister the plug-in on
uninstallation. This means that the plug-in executable should be run with the /RegPlugin
command switch near the end of a successful installation, and the plug-in executable should be run
with the /UnRegPlugin command switch before the plug-in components have been removed
during an uninstallation. The fact that registration is handled dynamically, by installed
components, means that the runtime of the plug-in must be complete at installation time. For
example, if the .NET Framework 2.0 is not yet installed, the plug-in registration will fail.
• Determine the L
ON W ORKS directory location at installation time by reading the value of the
HKEY_LOCAL_MACHINE\Software\LonWorks\LonWorks Path Windows registry string.
The path string will always be absolute, including the drive letter, but will not end in a slash “\”
character (for example, “c:\LonWorks”).
• Install your plug-ins in the LonWorks\Apps\[ManufacturerName]\[MyPluginName] directory, as
this is the convention. For example, if the L ON W ORKS directory is set to the default of
C:\LonWorks, Echelon is the manufacturer, and the plug-in is for the LonPoint plug-in, the
plug-in directory should be C:\LonWorks\Apps\Echelon\LonPoint.
• Install device files associated with your LNS device plug-ins, such as XIF, XFB, and APB files, in
the LonWorks \Import\[ManufacturerName]\[DeviceName]\[VersionName] directory, as this is
the convention (for example, C:\LonWorks\Import\Echelon\LonPoint\Version3”).
• Before your plug-in can add its registration data to the Windows registry, it must check to see if a
newer version of the plug-in is already installed. If so, your plug-in must not overwrite the
existing installation. Your plug-in can perform this check by using a Windows Installer product
version check.
Note: The LNS Framework Developer’s Kit installation and merge modules were created with
Macrovision InstallShield 11.5, and require Windows Installer version 3.1 (which will be installed by
the LNS Framework Developer’s Kit, if necessary). Any recent installation development tool that uses
Windows Installer and is designed for .NET redistribution should be sufficient for designing your
installation.