Building packages that work with the Web Player on Linux

When you develop extensions to be used with the Web Player service on a Linux computer, you must know this from the start and specify the intended platform when building your packages. The default when building packages is "Windows" so, if nothing else is specified, Windows packages will be built.

Note: There are different requirements for development on different platforms, and some functionality will not work on Linux. See the System Requirements for Spotfire Developer for more information.

Note: Building extensions for Linux is only supported using the Spotfire Package Builder console and not using the deprecated graphical Package Builder tool.

Some API:s in .NET only work on Windows and will throw an exception if used on Linux. For example, this applies to Windows Forms and other native Windows technologies. However, most of the .NET API:s are available in all of the flavors of .NET supported by Spotfire.

Another difference between different flavors of .NET is that in .NET core based code, more libraries are shipped as NuGet packages instead of being part of the installation of the .NET SDK or runtime. This means that such libraries must be packaged together with the custom extension when developing packages that should run on Linux.

Unless there is a need to compile native code, all extensions can be compiled using Visual Studio on Windows.

Linux-specific assemblies that are part of NuGet packages, and might be interesting to include, are automatically copied to the build folder. However, make sure to pick the right assembly. If an assembly from a NuGet package is multiplatform, the assembly in the folder bin/net{version} can be used also for a Linux package. But if the assembly is platform specific, the assembly should be picked from one of the "runtime" folders. For Linux packages, this is usually in a folder called bin/net/{version}/runtimes/linux/lib/net{version}, but sometimes, if the support for Linux and general Unix is the same, it could be found in a folder called bin/net{version}/runtimes/unix/lib/net{version}. One of the developer examples has a pkdesc file that takes that into account.

You determine which platform to build for by specifying the IntendedPlatform and TargetFramework attributes in your pkdesc file as described in Package Builder console parameter reference. If desired, you can also add an AlternativeID to override the package GUID.

Some data connectors require packaging of the driver .dll files from the NuGet package in an .spk file, to be deployed on the Spotfire Server. See Drivers and data sources in Spotfire (and search for Linux) for more information.

Example 1: Specifying that a pkdesc-file is targeted for Linux by default

Set IntendedPlatform in the PackageDescription element to "linux":

<PackageDescription
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" SchemaVersion="1.0"
Name="Package name" Version="1.0.0.0"
SeriesId="97D1819D-D5E4-4EF1-B722-2BC47B7DF9BB"
IntendedPlatform="linux">

Example 2: Specifying an alternative package id and package name that should be used for a Linux package build

<AlternativeId SeriesId="53A23DC0-33E6-4673-A331-86C61D578A99" Name="Package name-Linux" IntendedPlatform="linux" />

Example 3: Specifying that a File-element should only be included when the package is built for Windows

<File SourceFile="FileNameWin.dll" TargetFilename="FileNameWin.dll" Type="Assembly" IntendedPlatform="windows" />

Example 4: Specifying that a File-element should only be included when the package is built for Linux

<File SourceFile="FileNameLin.dll" TargetFilename="FileNameLin.dlll" Type="Assembly" IntendedPlatform="linux" />

Example 5: Elements specified for both Windows and Linux

<?xml version="1.0"?>
<PackageDescription xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" SchemaVersion="1.0" Name="Package name-Windows" Version="1.0.0.0" SeriesId="97D1819D-D5E4-4EF1-B722-2BC47B7DF9BB" IntendedPlatform="windows">
  <AlternativeId SeriesId="53A23DC0-33E6-4673-A331-86C61D578A99"  Name="Package name-Linux" IntendedPlatform="linux" />
  <File SourceFile="CommonFile.dll" TargetFilename="CommonFile.dll" Type="Assembly" />
  <File SourceFile="runtimes\win\lib\net8.0\WindowsFile.dll" TargetFilename="WindowsFile.dll" Type="Assembly" IntendedPlatform="windows" />
  <File SourceFile="runtimes\linux\lib\net8.0\LinuxFile.dll" TargetFilename="LinuxFile.dll" Type="Assembly" IntendedPlatform="linux" />
</PackageDescription>

If the pkdesc file is as described above and if the argument /intendedplatform:windows is given (or if no /intendedplatform is given, because the default is "windows") the following files will be present in the Contents folder in the spk file:

The first part of the module.xml file will have the following information:

<?xml version="1.0" encoding="utf-8"?>
<module>
<id>97d1819d-d5e4-4ef1-b722-2bc47b7df9bb</id>
<name>Package name-Windows</name>
<version>1.0.0.0</version>
<intendedClient>Core</intendedClient>
<intendedPlatform>WINDOWS</intendedPlatform>
<targetFramework>NETFRAMEWORK</targetFramework>

Here, the id and name are taken from the PackageDescription element which is the case when the argument /intendedplatform is the same as the default, or if intendedplatform is not given at all.

IntendedPlatform is specified to "WINDOWS" as expected.

Note that the module.xml file actually also contains a targetFramework element. This is automatically set to "NETFRAMEWORK" for Windows builds and to "NETCORE" for Linux builds.

If instead the argument /intendedplatform:linux is given with the same pkdesc file, the following files will be present in the Contents folder in the spk file:

Note that the archive is not in cab-format but instead in zip-format. Unless overridden on the command-line by using the existing argument /archiveformat, the default for Windows packages is "cab" and the default for Linux packages is "zip".

The first part of the module.xml file will have the following information:

<?xml version="1.0" encoding="utf-8"?>
<module>
<id>53a23dc0-33e6-4673-a331-86c61d578a99</id>
<name>Package name-Linux</name>
<version>1.0.0.0</version>
<intendedClient>Core</intendedClient>
<intendedPlatform>LINUX</intendedPlatform>
<targetFramework>NETCORE</targetFramework>

The id and name are in this case taken from the AlternativeId element and IntendedPlatform in module.xml is "LINUX" as expected.

Example 6: Building packages that can run on any platform

Certain types of packages might be applicable for any client, such as language packs and cobranding packages.

Set IntendedPlatform in the PackageDescription element to "universal", and the targetFramework to "any":

<PackageDescription
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" SchemaVersion="1.0"
Name="Package name" Version="1.0.0.0"
SeriesId="97D1819D-D5E4-4EF1-B722-2BC47B7DF9BB"
IntendedPlatform="universal"
TargetFramework="any">