Skip to main content
Skip Navigation LinksHome  Extending the Spotfire Platform  Extensions

©Spotfire 2011

Extensions

A Spotfire extension is the smallest functional unit added to the platform. It is developed in Visual Studio® and is included in a Spotfire add-in, enabling versioning, licensing, deployment and loading.

Overview

This page first describes the key concepts to develop extensions adding custom capabilities to the Spotfire platform. Next, the development procedure is outlined from template to deployment. Then, the artifacts that must be produced for different scenarios are listed. Finally there is a recommendaton on the use of 32-bit DLLs on 64-bit platforms.

See also:
  • Creating Extensions to the Spotfire Platform
    A Spotfire solution to a complex problem may require a design with several specialized extensions. Still, a single extension based on an SDK example project will often do. The examples are fully functional solutions to common problems, and there are many ways to combine them. This page describes the available extension points, often with links to pages detailing the use, the limitations and the technical aspects of the extension point, mostly referencing the applicable SDK example.
  • Spotfire SDK
    The SDK provides required Spotfire developer resources: the Spotfire Extension Project Template, development assemblies, example projects, and the Package Builder application wrapping the extensions for deployment.

Concepts

Extensions are bundled for loading into Spotfire in units called add-ins. Spotfire version handles, deploys and loads functionality as add-ins registering extensions.

A Spotfire add-in is implemented as a C# project in Visual Studio®. The design guidelines for Spotfire extensions prescribes that every add-in contains one class derived from the AddIn class. An add-in is basically defined by information provided when creating the project from the SDK template. The add-in project contains one or more extensions. Additional extensions can easily be added to the project at a later point in time to build a new version.

Each extension is implemented in a set of classes, typically overriding a base class defining a specific extension type. The add-in registrations are made declaratively by overriding an extension type specific method, Register[ExtensionType](). Each such method is passed a registrar that allows the add-in to register the extension in the appropriate registry in Spotfire. For instance, to register a new tool, the RegisterTools(ToolRegistrar) is overridden. A similar procedure is used when licensing extensions.

An add-in can also register services that can be used by other add-ins. This provides a simple way for add-ins to provide extension points of their own.

A module is defined as qualified for loading in Spotfire if it has a valid module definition file file. It declares the add-in to the application by defining the fully qualified type name for the AddIn class and the assembly name. It also declares a unique project GUID and a strong name for the assembly. Combinations of these uniquely identifies the project and the add-in. Extension assemblies must therefore be signed with a strong name key using a strong name key file (.snk). The extension project template contains a default key. You may replace this key file with your own, but if you do, make sure to alter the module definition file accordingly.

Construction Procedure from Template to Deployment

Extending the Spotfire Platform is a straightforward procedure based on the extension mechanism:

  1. Break down the problem and determine the appropriate extension points to use.
  2. Register an extension for each point.
  3. Implement the base classes tied to the respective extension points.

The recommended procedure requires Visual Studio® and Spotfire Package Builder:

  1. In Visual Studio®, open an existing extension or create a new extension, preferably from the TIBCO Spotfire Extension Template, and build it.
  2. In Package Builder, add the extension to a configuration that includes the default Spotfire client.
  3. In Visual Studio®, develop and debug the extension.
  4. In Package Builder, build a Spotfire Package file containing the extension.
  5. Use TIBCO Spotfire Administration Console to deploy the Spotfire Package file to a Spotfire Server.

Upon deployment, users will be prompted to download updates when they start their clients and access the server. If the end user accepts the prompt, the extension is downloaded to the client computer, the client is restarted and the extension is loaded into the running Spotfire instance.

For Spotfire 2.0 and 2.1 extension development, refer to procedures based on the earlier Package Builder application.

Extension Artifacts

The Model-View division lies at heart of extension construction. It applies from the setting up of the Visual Studio project with add-in definitions, to assembly packaging when adding the corresponding project in Package Builder. An extension containing a model and a view is implemented in a Visual Studio solution containing at least two projects and two add-ins, and will be deployed as, at least, two Spotfire packages.

Model Add-Ins

Implement the model parts using the core Spotfire APIs and define the add-in in a Visual Studio project. When creating the Spotfire Package Builder project, set the Intended client project option to TIBCO Spotfire Any Client.

View Add-Ins

Extension views are also set up as Visual Studio projects. They define their own add-ins, registering the view by overriding the RegisterViews method. They must also define dependencies to the project implementing the model that is used by view. Since views target either Spotfire Professional or Spotfire Web Player, the Intended client for the Package Builder project corresponding to the view is either set to TIBCO Spotfire Professional/Enterprise Player or TIBCO Spotfire Web Player.

Extension Artifacts Example

The following figure illustrates an extension with one model component and two views, one for Spotfire Professional and one for Spotfire Web Player:

From Visual Studio project via Package Builder to Spotfire package

This construction is required when creating a new visualzation to be rendered in both clients. Note that the web view is rare: The only supported web views are custom visualization and export tool prompting.

Extensions on 64-Bit Platforms

64-bit (x64) platforms, as opposed to 32-bit (x86), are becoming more common. For TIBCO Spotfire Web Player it can be considered the default platform, mainly because of the ability to address up to 8TB of memory, considerably higher than the maximum of 2 GB for 32-bit processes.

On a 64-bit platform, TIBCO Spotfire is always launched in a 64-bit process. This is usually not a problem for a custom extension as long as the extension is compiled for a neutral platform target (Any CPU). If the custom extension uses a third party native 32-bit DLL to run on a 64-bit platform, the 32-bit DLL must be executed in a separate 32-bit process. In this case the custom extension must communicate with the third party DLL through inter-process communication (IPC). In other words, 64-bit and 32-bit processes can exchange data using IPC techniques such as out-of-process COM, sockets, message services or memory mapped files.
For more information on IPC, refer to MSDN on Interprocess Communications.

Implementing the IPC-based communication between your custom extension and the third party component may require considerable work. Check if a 64-bit version of the third party component is available. If it is, the recommended solution is to include both the 32-bit and the 64-bit version in the distribution, using different names for the DLLs, and perform a platform invocation call to the correct DLL based on the current architecture. The following test determines if the current architecture is 32-bit:

Marshal.SizeOf(typeof(IntPtr)) == 4;

For more information, refer to MSDN on Platform Invoke Services (PInvoke), especially the Platform Invoke Tutorial.

Note: When running a third party component in a separate process it is not possible, for technical reasons, to have any UI interaction (such as an ActiveX control) in that component. If such interaction is required, make sure to do it in the custom extension executed in the main process.