Echelon LNS Plug-in User Manual

LNS

®

Plug-in Programmer’s Guide

Release 4

®

0 7 8 - 0 3 9 3 - 0 1 A

Echelon, LON, LonWorks, Neuron, 3120, 3150, Digital Home,
i.LON, LNS, LonMaker, LonMark, LonPoint, LonTalk,
NodeBuilder, ShortStack, and the Echelon logo are
trademarks of Echelon Corporation registered in the United
States and other countries. FTXL, LonScanner, LonSupport, ISI,
OpenLDV, and LNS Powered by Echelon are trademarks of
Echelon Corporation.

Other brand and product names are trademarks or
registered trademarks of their respective holders.

Neuron

Chips and other OEM Products were not designed for

use in equipment or systems which involve danger to human
health or safety or a risk of property damage and Echelon
assumes no responsibility or liability for use of the Neuron
Chips or LonPoint Modules in such applications.

Parts manufactured by vendors other than Echelon and
referenced in this document have been described for
illustrative purposes only, and may not have been tested by
Echelon. It is the responsibility of the customer to determine
the suitability of these parts for each application.

ECHELON MAKES NO REPRESENTATION, WARRANTY, OR
CONDITION OF ANY KIND, EXPRESS, IMPLIED, STATUTORY, OR
OTHERWISE OR IN ANY COMMUNICATION WITH YOU,
INCLUDING, BUT NOT LIMITED TO, ANY IMPLIED WARRANTIES OF
MERCHANTABILITY, SATISFACTORY QUALITY, FITNESS FOR ANY
PARTICULAR PURPOSE, NONINFRINGEMENT, AND THEIR
EQUIVALENTS.

No part of this publication may be reproduced, stored in a
retrieval system, or transmitted, in any form or by any means,
electronic, mechanical, photocopying, recording, or
otherwise, without the prior written permission of Echelon
Corporation.

Printed in the United States of America.
Copyright ©1997–2009 by Echelon
Corporation.
Echelon Corporation
www.echelon.com

Table of Contents

Preface .................................................................................................... vi

Purpose ..........................................................................................................vii

Audience.........................................................................................................vii

Software Requirements..................................................................................vii

Content...........................................................................................................vii

Related Manuals.............................................................................................vii

Other Related Material ..................................................................................viii

For More Information and Technical Support................................................viii

1 Introduction ....................................................................................... 1

Introduction......................................................................................................2

Overview of Plug-ins.................................................................................2

Types of Plug-ins................................................................................2

LNS Plug-in Commands.....................................................................3

LNS Plug-in Properties.......................................................................3

Overview of the LNS Plug-in Framework Developer’s Kit ........................3

2 Creating and Redistributing LNS Device Plug-ins......................... 5

Creating and Redistributing Plug-ins Overview...............................................6

Installing the Developer’s Kit...........................................................................6

Creating the Plug-in Project......................................................................8

Creating the Plug-in Source Files..................................................................11

Implementing the Plug-in Server Class...................................................12

Implementing the Plug-in Object Class...................................................12

Implementing the Plug-in Form Class.....................................................17

Registering DeviceTemplate and LonMarkObject Scoped Plug-in

Commands ....................................................................................................

Debugging Plug-ins.......................................................................................19

Redistributing your Plug-in ............................................................................20

19

3 How Plug-ins Work with Directors................................................. 21

How Plug-ins are Represented In the LNS Object Server............................22

How Plug-ins are Installed and Made Visible to LNS....................................22

How Plug-ins Implement the Registration Command ...................................23

How Plug-ins Respond to Commands from a Director Other than

Registration....................................................................................................

How Directors Launch and Manipulate Plug-ins ...........................................25

How Directors Support Prelaunch...........................................................27

How Directors Support MultiObject and SingleInstance.........................27

How Directors Pass Object Names.........................................................29

How Plug-ins Let Directors Know About Errors......................................29

How Plug-ins Know When To Exit..........................................................29

What Plug-ins Do When They Run in Standalone Mode..............................30

Responding to Property Reads and Writes...................................................30

Uninstallation Issues......................................................................................31

25

Appendix A Standard Plug-in Commands......................................... 33

Appendix B Standard Plug-in Properties........................................... 35

Appendix C Standard Plug-in Object Classes................................... 41

Appendix D Standard Plug-in Exceptions ......................................... 45

Appendix E Glossary........................................................................... 47

Appendix F Running the ACME Example C# Plug-in........................ 51

Preface

You can use LNS device plug-ins to simplify the installation of your devices for network

integrators. This manual provides an overview of the LNS Plug-in API and how plug-ins

and director applications such as the LonMaker Integration Tool interact. It describes

how to install the LNS Plug-in Framework Developer’s Kit, which implements the LNS

Plug-in API and provides a set of framework assemblies that let you efficiently develop

and redistribute LNS plug-ins. It explains how to write device plug-ins using .NET

programming languages such as C# and Visual Basic .NET, and how to redistribute your

LNS device plug-ins.

Purpose

This document describes how to write LNS plug-ins using .NET programming languages such as C#
and Visual Basic .NET. After reading this document, you should understand the basic mechanics of
how plug-ins work, and how to write a plug -in usi n g t he LNS Pl u g-in Framework.

Audience

Users of this document should have a basic understanding of the LNS Object Server, and experience
programming in C#, Visual Basic .NET, or another .NET programming language.

Software Requirements

Software requirements for computers running the LNS Plug-in Framework Developer’s Kit are listed
below:

• Microsoft Windows Vista™, Microsoft Windows XP, Windows 2000, or Windows Server 2003.

Echelon recommends that you install the latest service pack available from Micro soft for your
version of Windows.

• Microsoft .NET Framework Version 2.0 Redistributable Package. To check whether your

computer has this software and download it (if necessary), go to the Microsoft Windows Update
Web page at

• Microsoft Visual Studio 2005 Professional E di t i on o r hi g he r. Microsoft Visual Studio Express

editions may work, but they have not been tested.

http://update.microsoft.com.

• LNS Server Turbo Edition (3.22 or later).

• LNS Turbo plug-in director application. This may be the LonMaker Integration Tool Turbo

Edition (3.2 or later) or the LNS Turbo ADK Plug-in Director example application.

Content

This guide includes the following content:

•

Introduction: Describes the types of plug-ins that are used with LONWORKS networks, and it
describes how director applications request act i ons fr om plug-ins. Explains how the LNS Plug-in
Framework allows plug-ins to function in the .NET environment and interface with COM-based
director applications.

Creating and Redistributing LNS Device Plug-ins: Explains how to create an LNS device plug-in

•

project using the LNS Plug-in Framework Developer’s Kit, how to debug your plug-ins, and how
to create an installation project for your plug-in so th at you can provide it to users.

How Plug-ins Work with Directors: Summarizes the life cycle of a plug-in. It describes how

•

plug-ins make themselves known to directors, how plug-ins let directors know what they can do,
and how directors and plug-ins interact. Provides examples of how these tasks should be
performed.

• Appendixes: Includes listings of standard plug-in commands, properties, classes, and exceptions;

a glossary that provides definitions for key terms and concepts associated with programming
plug-ins; and a demonstration of plug-in behavior using the example ACME C# plug-in that is
installed by the LNS Plug-in Framework Developer’s Kit.

Related Manuals

The following manuals provide supplemental information to the material in this guide. You can
download these documents from Echelon’s Web site at

www.echelon.com.

LNS®Programmer’s Guide

LonMaker

®

User’s Guide

Describes how to use the LNS Object Server ActiveX Control to
develop an LNS application on a Microsoft Windows Vista
Server 2003, Windows XP, or Windows 2000 host computer.

Describes how to use the LonMaker Integration Tool to design,
commission, modify, and maintain L

ONWORKS networks.

Other Related Material

This document refers to and describes the LNS Plug-in API that all plug-ins use. Because plug-ins
work together with directors, a director is needed in order to fully test and debug the plug-ins that you
write. While any director can be used for this purpose, this guide describes the use of the LonMaker
tool as the director. See the LonMaker User’s Guide for more detailed information on the use of the
LonMaker tool.

For More Information and Technical Support

The LNS Plug-in Framework Online Help details the Echelon.LNS.Plugin and
ACME.DevicePlugin namespaces. The Echelon.LNS.Plugin namespace contains a framework of

interfaces, classes and other types for creating .NET-based LNS Plug-ins. The ACME.DevicePlugin
namespace contains example device plug-ins written in C# and Visual Basic that use the LNS Plug-in
Framework. To view the LNS Plug-in Framework Online Help, click Start, point to Programs, point
to Echelon LNS Plug-in Framework Developer’s Kit, and then select LNS Plug-in Framework
Online Help.

The ReadMe First file for the LNS Plug-in Framework provides descriptions of known problems, if
any, and their workarounds. To view this ReadMe file, click Start, point to Programs, point to
Echelon LNS Plug-in Framework Developer’s Kit, and then select ReadMe First. For additional
information, you can go to Echelon’s Development Tools Web pages at

www.echelon.com/products/development.

™

,

If you have technical questions regarding the programming of LNS plug-ins not answered by this
document, the LNS Plug-in Framework Online Help, or the ReadMe First file, you can contact
technical support. To receive technical support from Echelon, you must purchase support services
from Echelon or an Echelon support partner. See
Echelon support and training services.

You can obtain technical support via phone, fax, or e-mail from your closest Echelon support center.
The contact information is as follows:

Region Languages Supported Contact Information

The Americas

English
Japanese

www.echelon.com/support for more information on

Echelon Corporation
Attn. Customer Support
550 Meridian Avenue
San Jose, CA 95126
Phone (toll-free):
1-800-258-4LON (258-4566)
Phone: [phone]
Fax: [phone]

[e-mail]

Region Languages Supported Contact Information

Europe

English
German
French
Italian

Echelon Europe Ltd.
Suite 12
Building 6
Croxley Green Business Park
Hatters Lane
Watford
Hertfordshire WD18 8YH
United Kingdom
Phone: [phone]
Fax: [phone]

[e-mail]

Japan

Japanese Echelon Japan

Holland Hills Mori Tower, 18F
5-11-2 Toranomon, Minato-ku
Tokyo 105-0001
Japan
Phone: [phone]
Fax: [phone]

[e-mail]

China

Chinese
English

Echelon Greater China
Rm. 1007-1008, IBM Tower
Pacific Century Place
2A Gong Ti Bei Lu
Chaoyang District
Beijing 100027, China
Phone: [phone]
Fax: [phone]

[e-mail]

Other Regions

English Phone: [phone]

Fax: [phone]

[e-mail]

You can submit a feedback form with suggestions on how to improve the product’s functionality and
documentation at

www.echelon.com/company/feedback. This feedback form is not forwarded to

technical support and should not be used to submit technical or product support related issues. Please
send technical support questions to your Echelon support center.

Introduction

This chapter describes the types of plug-ins that are used with LONWORKS networks,

and it describes how director applications request actions from plug-ins. It explains

how the LNS Plug-in Framework allows plug-ins to function in the .NET

environment and interface with director applications.

1

Introduction

An LNS plug-in is an out-of-process automation server that implements the COM-based LNS Plug-in
API so that it may be instantiated and controlled by an LNS plug-in director application. Plug-ins
provide a standard way to extend and customize the functionality of LNS applications. For example,
plug-ins allow device manufacturers to provide customized software that simplifies the configuration,
monitoring, or control of their devices (plug-ins that are specific to a particular type of device are
sometimes referred to as device plug-ins). Plug-ins can also add new functionality to LNS applications
such as alarming, logging, and trending. The LNS Plug-in API is further described in Chapter 3,
Plug-ins Work with Directors.

An LNS plug-in director applicat i on (herein referred to as a director) is a complex, general-purpose
network manager that is extensible in its functionality, because it can call LNS plug-ins. For example
Echelon’s LonMaker Integration Tool is an LNS plug-in director application that can call LNS
plug-ins to extend its functionality—typically to perform manufacturer-specific device configuration.

When a plug-in is installed on a computer, the setup program installs a number of items for the plug- in
to the computer’s registry. This enables directors to determine which plug-ins a user has installed on
their computer and call the plug-ins at appropriate times. Directors can make access to plug-ins
completely transparent to the end-user. This means that the user cannot tell when a task is built-in to
the director and when it is being provided by a plug-in called by the director.

Plug-ins provide many benefits to network integrators, who are the end-users of tools. Plug-ins make
tools easier to use and make network integrators more productive. They reduce the cost of training
network integrators on the use of tools. They also reduce the time and cost of installing, configuring,
and maintaining systems.

Tool and device manufacturers also benefit from plug-ins. For tool manufacturers, plug-ins make tools
extensible and thus more valuable. Network integrators can incrementally add features—from the
tool’s manufacturer or from other plug-in vendors—to adapt the tool to their needs. A tool that
supports plug-ins is a tool that will become easier to use, more productive, and more powerful over
time.

How

For device manufacturers, plug-ins allow them to make their devices easy to install, configure, and
maintain—without the cost of having to develop an entire, customized tool. Devices that come with
plug-ins have a competitive edge: they are cheaper to install and service, and they are easier to use.

The LNS Plug-in Framework Developer’s Kit allows plug-ins to function in the .NET environment and
interoperate with COM-based directors. It includes the .NET components needed for interfacing with
the COM-based LNS API in the .NET environment. It provides a set of example software and
framework assemblies that let you efficiently develop plug-ins with the latest .NET programming tools
and re-distribute your plug-ins. It provides the plug-in API an d COM interaction so that you do not
need to provide it in your .NET application.

Overview of Plug-ins

A plug-in is a type of LNS application that implements the COM-based LNS Plug-in API. The Plug-in
API consists of the LNS Plug-in Commands (see Appendix A,
Plug-in Properties (see Appendix B,
Appendix D,
example, by the set of commands that it provides and by the class of objects that each command
operates on). For example, a plug-in might implement two actions, a test command of AppDevice
class objects and a test command of Router class objects.

Standard Plug-in Exceptions). A plug-in is defined by the actions that it can perform (for

Standard Plug-in Properties), and LNS Plug-in Exceptions (see

Types of Plug-ins

There are two types of plug-ins: device plug-ins and system plug-ins.
Device plug-ins apply to a single device or a single functional block within a device. For example, you

could create a device plug-in for a device developed with the NodeBuilder tool that allows users to set

Standard Plug-in Commands), the LNS

configuration properties and enforce limits on configuration property values. You can create a device
plug-in executable that operates on multiple device types. The single executable that is able to operate
on multiple device types is a programming convenience. You can also create a separate device plug-in
for each functional block in a device, but it is typical to include the support for all functional blocks of
a device type in a single plug-in, and let the plug-in determine which object to act upon based on the
object that has been passed as a parameter.

System plug-ins apply to an entire network. For example, a system plug-in could provide a custom
interface that would allow you to test all devices on a network and see the results. A system plug-in
could also be designed to manage all of the devices in a room, or on a floor of a building. This
document focuses on device plug-ins; however, you can also implement a system plug-in based on the
instructions in Chapter 2,

The LNS Plug-in API defines a single method, SendCommand(), and a number of properties that a
plug-in must implement.

Creating and Redistributing LNS Device Plug-ins.

LNS Plug-in Commands

The SendCommand() method is used by directors to ask a plug-in to perform a command (specified
by ID) on an object (specified by class ID and object path). Plug-ins can implement standard
commands defined by LNS or custom commands that they define. The plug-in designer is responsible
for having the plug-in implement commands in a way that makes sense (for example, if a plug-in
implements the Browse command, the plug-in designer must design the implementation of the
plug-in’s Browse command). The standard plug-in commands are listed in Appendix A,
Plug-in Commands.

Device plug-ins typically implement the LcaCommandConfigure command. This command is used
by network tools to provide an option for network integrators to configure a device or functional block.
Device plug-ins may also implement the LcaCommandBrowse command if they are used for
monitoring and controlling the device in addition to configuring it. The device plug-in can also decide
whether to display the same user interface for these two commands.

Standard

Plug-ins can also implement custom commands. The values for custom command IDs are assigned by
the plug-in, and may be any value greater than or equal to LcaCommandUserStart (10000).

LNS Plug-in Properties

All plug-ins must also implement a standard set of properties along with any custom properties
required by the developer. The standard properties allow the director to tell the plug-in information
about the network is it operating on (such as the NetworkName and the NetworkInterfaceName
properties) as well as to control the appearance of the plug-in (such as the Left, Height, and Visible
properties). The complete list of required and optional properties is given in Appendix B,
Plug-in Properties. Read access must be provided to all properties. Write access may optionally be
provided for most properties; however, some properties must be read-only or must be read-write as
noted in Appendix B,

Standard Plug-in Properties.

Standard

Overview of the LNS Plug-in Framework Developer’s Kit

The LNS Plug-in Framework Developer’s Kit includes the following components needed for
interfacing with the COM-based LNS API in the .NET environment: the LNS Plug-in Framework and
the LNS .NET wrapper.

The LNS Plug-in Framework is a library of classes, interfaces, and value types that provides access to
LNS Plug-in functionality and is designed to be the foundation on which .NET-based plug-ins are
built. The LNS Plug-in Framework provides the following components:

• A COM Callable Wrapper (CCW) that lets a COM director application, such as the LonMaker

tool, call into the .NET plug-in assembly.

• An implementation of the full LNS Plug-in API interface (ILnsPlugin).

• A simple out-of-process server task model that supports plug-ins in the .NET environment (LNS

plug-ins are out-of-process COM servers, for which support in the .NET environment is not well
documented).

The LNS .NET wrapper is the Primary Interop Assembly, which is generated by Echelon and

distributed with LNS. It provides a Run-time Callable Wrapper (RCW) that allows your .NET
plug-in to interface with the COM-based LNS API. Note that the LNS .NET wrapper is required for
plug-in development with .NET, but is not considered part of the LNS Plug-in Framework because it
may also be used by LNS applications that are not plug-ins. The LNS Primary Interop Assembly is
included with the LNS runtime components starting in LNS 3.23. If your plug-in is targeted for LNS

3.23 or later, you do not need to include the LNS 3.22 Primary Interop Assembly that is included
with the LNS Plug-in Developer’s Kit, version 1.1.

The LNS Plug-in Framework is implemented as a set of base classes that your plug-in will inherit and
extend. These classes are documented by the LNS Plug-in Framework Online Help. The use of
these classes is demonstrated in the

Creating the Plug-in Source Files section in Chapter 2.

• PluginObjectBase. This class contains the basic framework implementation of the LNS Plug-in

API methods and properties.

• PluginServerBase. This class works in conjunction with PluginObjectBase. It contains the

process model handling for the out-of-process server.

• PluginFormBase. This class contains the base class for the optional user interface instantiation of

the plug-in. This may not be necessary in all plug-ins, since some plug-ins may not have user
interfaces.

Creating and Redistributing LNS

Device Plug-ins

This chapter explains how to create an LNS device plug-in using the LNS Plug-in

Framework Developer’s Kit, how to debug your plug-ins, and how to create an

installation project for your plug-in so that you can provide it to users.

2

Creating and Redistributing Plug-ins Overview

You can use the LNS Plug-in Framework Developer’s Kit to create an LNS device plug-in and create
an installation project for your plug-in so that you can prov ide it to users.

To create a new plug-in, you need to first install the Microsoft .NET Framework Version 2.0
Redistributable Package. You then need to install the LNS Plug-in Framework Developer’s Kit and an
LNS Turbo plug-in director application such as the LonMaker Tool Turbo Edition (3.2 or later) if they
are not already installed on your computer. You need a director application to test your plug-in during
development.

After the required software is installed on your computer, you can begin creating your plug-in. To do
this, you create a new C# or VB.NET plug-in project with Microsoft Visual Studio 2005 (or later),
create the plug-in source files (for the plug-in server, plug-in object, and plug-in form derived classes),
and optionally implement command registration for the DeviceTemplate and LonMarkObject scoped
plug-in commands (note that this is not automatically implemented for you by the LNS Plug-in
Framework, version 1.1).

During the development of your plug-in, you can debug it by generating trace information and using
the OLE/COM ObjectViewer to display the registration information.

After you create your device plug-in, you can create an LNS p lug-in installer based on the framework
so that you can redistribute your plug-in.

Note: During development, you can also refer to the ACME plug-in example that is installed on your
computer by the LNS Plug-in Framework Developer’s Kit. The ACME plug-in example is located in
the LonWorks\ObjectServer\Examples\PluginFramework folder on your computer, and it is provided
in both C# and VB.NET programming languages. For more information on using the ACME C#
plug-in example to view the behavior of a plug-in, see Appendix F,

Plug-in.

Running the ACME Example C#

Installing the Developer’s Kit

The LNS Plug-in Framework Developer’s Kit is automatically installed by the NodeBuilder FX tool,
and it is also available as a single-executable installer that you can download from the Echelon Web
site. To install the developer’s kit, follow these steps:

1. Install the Microsoft .NET Framework Version 2.0 Redistributable Package (or newer) if it is not

already installed on your computer. The LNS Plug-in Framework and example plug-in will not
install or run properly unless the .NET 2.0 Framework (or newer) is installed on your computer.

Redistributing Your Plug-in later in this chapter for details. To check whether your computer

See
has this software and download it (if necessary), go to the Microsoft Windows Update Web page

http://update.microsoft.com.

at

2. Install the LNS director application that will be used for plug-in testing. If not already set, this

will set the root directory for the LNS components (for most Echelon products, this directory will
appear by default at [Windows System Drive]\LonWorks, and is known as the LonWorks
directory). It will also install the LNS runtime that is required to successfully run the ACME
example plug-in.

3. If you do not have the NodeBuilder FX tool installed on your computer, download the LNS

Plug-in Developer’s Kit from the Echelon Web site at

www.echelon.com/support/downloads, and then install it.

http://

4. After the LNS Plug-in Framework Developer’s Kit and other requirements have been installed

(either by installing the NodeBuilder FX tool, or downloading it from the Echelon and installing it
standlaone), the following folders will reside in the LonWorks directory on your computer.

• The ObjectServer folder is common to all computers with the LNS Server runtime installed.

• The Assemblies folder contains the .NET assemblies referenced by plug-ins that are built

using the framework. Visual Studio is informed of this directory by a registry entry added
during the installation. This makes the assembly information accessible to the development
environment. These assemblies are also installed directly into the Global Assembly Cache for
runtime support of framework-based plug-ins.

• The Apps folder is used by convention to redistribute LNS plug-ins. The sub-directory under

the Apps folder should give the plug-in manufacturer’s name (for example, this folder
contains an “ACME” subdirectory containing the provided example plug-in). Under the
manufacturer’s directory, there should be a directory specific to each individual plug-in
created by your company. For example, there is an Example folder under the
LonWorks\Apps\ACME directory rep resenting one plug-in created by the ACME company.
If the ACME company created another plug-in named “Example2”, it would be stored in an
Example2 folder under the LonWorks\Apps\ACME directory.

• The Examples folder contains example LNS applications.

• The Documentation folder contains a ReadMe file, a PDF of this manual, the LNS Plug-in

Framework Online Help, and a Visio drawing illustrating the plug-in instantiation models.

• The MergeModules folder contains merge modules for the two .NET assemblies referenced

by framework-driven plug-ins. These merge modules should be included in your installation
when you redistribute a plug-in developed with the Kit. See

Redistributing Your Plug-ins

later in this chapter for details.

• The ExampleCSPlugin folder and sub-directories contain source code and Visual Studio

2005 project files for the ACME Example C# Plug-in.

• The ExampleVBPlugin folder and sub-directories contain source code and Visual Studio

2005 project files for the ACME Example VB.NET Plug-in. This example was created by
translating the C# version of the example plug-in source code to the VB.NET language.

5. After the installation has successfully completed, an Echelon Plug-in Framework Developer’s

Kit program folder will appear in the Windows program folders. Shortcuts within this folder
provide access to the ReadMe file, a PDF of this manual, the LNS Plug-in Framework online help
file, the standalone example plug-in executable, and the C# and VB.NET examples.

Creating the Plug-in Project

You can create a C# or VB.NET plug-in project using Microsoft Visual Studio 2005 (or later)
following these steps (note that the example shown in this section is a C# plug-in project created with
Microsoft Visual Studio 2005 Professional Edition):

1. Create a new C# or Visual Basic Windows Application project. The project must create an EXE

target. Specify a name and location for your project. Click OK.

2. Click Project and then click your application’s Properties option. The Application tab opens.

3. Modify and confirm the following project properties:

• In the Default namespace property, change the namespace to

<YourCompany>.<YourProject>.

• In the Assembly name property, enter a unique and descriptive assembly name that matches

your selected namespace (for example, <YourCompany>.<YourProject>.<YourPlugin>).

• In the Output type property, verify that Windows Application is specified.

• In the Icon property under the Resources box, specify an icon.

4. Click Assembly Information. The Assembly Information dialog opens.

5. Enter the information describing your plug-in assembly, and then click OK to save the

information and return to the Application tab.

6. Click the Build Events tab.

7. Copy the PostBuild.bat file from the

LonWorks\ObjectServer\Examples\PluginFramework\ExampleCSPlugin to your project folder.

8. In the Post-build event command line property, enter the following line:

Call "$(ProjectDir)PostBuild.bat" "$(TargetP a th) "

The PostBuild.bat file will carry out the post-build actions necessary to register your plug-in
during the development process. Specifically, it generates a C OM Type Li brary and registers the
assembly for use with COM using RegAsm /tlb, and it registers the plug-in with LNS directors by
calling the plug-in with a /RegPlugin argument.

9. In the Run the post-build event property, select the When the build updates the project output

option.

10. Click the Debug tab.

11. In the Command line arguments property, enter -Embedding. This enables debugging of the

server.

12. Click Project and then click Add Reference. The Add Reference dialog opens.

13. Select the Echelon.LNS.Interop and the Echelon.LNS.Plugin.Framework .NET assemblies,

and then click OK.

• Echelon.LNS.Interop enables your application to interact with LNS.

• Echelon.LNS.Plugin.Framework provides the base functionality for your plug-in.

Creating the Plug-in Source Files

After you create your LNS plug-in project, you need to create the plug-in source files. To do this, you
create three classes: plug-in server, plug-in object, and plug-in form, which are to be derived from the
PluginServerBase, PluginObjectBase, and PluginFormBase base classes, respectively. After you
create these classes, you then modify them as described in the subsequent sections.

To create the plug-in server, plug-in object, and plug-in form classes, follow these steps:

1. In the Solution Explorer pane, delete the automatically generated Program and Form1 files.

2. Create the plug-in server class. To do this, follow these steps:

a. Click Project and then click Add Class. The Add New Item dialog opens.
b. In the Name property, enter <YourPlugin>Server, where YourPlugin is the name of your

plug-in, and then click Add.

3. Create the plug-in object class. To do this, follow these steps:

a. Click Project and then click Add Class. The Add New Item dialog opens.
b. In the Name property, enter <YourPlugin>Object, where YourPlugin is the name of your

plug-in, and then click Add.

4. Create the plug-in form class, which is a Windows Form item. To do this, follow these steps:

a. Click Project and then click Add Windows Form. The Add New Item dialog opens.
b. In the Name property, enter <YourPlugin>Form, where YourPlugin is the name of your

plug-in, and then click Add

The following subsections describe how to implement your plug-in server, plug-in object, and plug-in
form classes.

.