Tekniq mark
Tekniq SDK Docs

External Developer Setup

License, signing, deployment and runtime validation for external developers

Onboarding first License, signing, deployment and runtime validation for external developers
Audience: External developers Language: English Area: Licensing

External Developer Setup

This guide explains exactly how to prepare, sign, deploy, and validate a Tekla plugin that uses the Tekniq SDK.

It is written for external developers and focuses on practical setup steps, required code, build commands, file locations, and runtime checks.

Use this page as your onboarding checklist when starting a new plugin or when integrating the SDK into an existing plugin project.

1. Before you start

Before you begin, make sure you already have the following from Tekniq:

  • A copy of TekniqSDK.dll
  • Your developer GUID
  • The signing tool, for example TekniqSignLocal.exe during the current testing phase
  • The expected Tekla extension deployment folder for your plugin
  • The correct startup class or plugin entry point in your solution
Important: your developer GUID is part of the validation flow. Do not invent one yourself. Use the GUID supplied by Tekniq.

2. What you will build

After following this guide, your plugin will support both build-time signing and runtime license validation.

At build time

  • Your plugin DLL is compiled
  • The signing tool reads your assembly metadata
  • A .tekniqlicense sidecar file is generated next to the DLL
  • Both files are copied to the Tekla extension folder

At runtime

  • The plugin calls TekniqSdk.Initialize(...)
  • The SDK reads the developer GUID from your assembly
  • The SDK locates the sidecar license file
  • The SDK validates that the plugin DLL and sidecar belong together

3. Step 1 – Add the SDK reference

Open your Visual Studio solution and add a reference to TekniqSDK.dll in the plugin project that will be loaded by Tekla.

Where to do this

  1. Right-click the plugin project
  2. Select Add Reference
  3. Browse to TekniqSDK.dll
  4. Add the reference and save

What this enables

  • Access to TekniqSdk.Initialize()
  • Access to TekniqDeveloperAttribute
  • Access to the runtime verification flow

4. Step 2 – Add your developer identity

Your plugin assembly must contain the developer GUID assigned to you. The signing tool reads this value from the compiled assembly, and the SDK checks that the sidecar file matches it.

Where to do this

Add it in a file that is compiled into your plugin assembly, for example:

  • AssemblyInfo.cs
  • or a dedicated file such as TekniqDeveloperInfo.cs

Code to add

using TekniqSDK.Licensing;

[assembly: TekniqDeveloper("YOUR-DEVELOPER-GUID-HERE")]

Example

using TekniqSDK.Licensing;

[assembly: TekniqDeveloper("2cc4ae73-1da8-458d-a64a-2b3f671f7e8f")]
Do not skip this. If the attribute is missing, the signing tool or runtime verification will fail.

5. Step 3 – Initialize the SDK in code

The SDK must be initialized during plugin startup, before your plugin depends on SDK-backed functionality.

Where to do this

Place the call inside the startup class, feature class, or main entry point of the plugin assembly that Tekla loads.

Recommended code

TekniqSdk.Initialize(typeof(StartUpFeature).Assembly);

Real-world pattern

public override bool Run(List<InputDefinition> userPickerInput)
{
    TekniqSdk.Initialize(typeof(PluginTemplatePlugin).Assembly);
    TekniqSdk.RequireInitialized();
    TekniqSdk.RequireLicensed();

    // Continue with your normal plugin logic here.
}

Why the assembly is passed explicitly

In Tekla and Fusion-related scenarios, automatic calling-assembly detection can be unreliable. Passing the plugin assembly explicitly prevents wrong assembly resolution.

Use the actual plugin assembly. Do not pass a helper assembly or a shared library if the plugin DLL loaded by Tekla is different.

6. Step 4 – Add the post-build signing step

After your DLL is compiled, the signing tool should generate a matching .tekniqlicense file. This is usually done with a post-build event.

Where to do this

Add the command in your project build events or in your project file build target.

Example post-build script

echo START TEKNIQ SIGN LOCAL
"$(ProjectDir)Tools\TekniqSignLocal.exe" --dll "$(TargetPath)" --email "your@email.com" --module "TekniqSDK"
echo END TEKNIQ SIGN LOCAL

set TARGET_FOLDER=C:\TeklaStructures\2025.0\Environments\common\extensions\Features\MyPlugin\

copy /Y "$(TargetPath)" "%TARGET_FOLDER%"
copy /Y "$(TargetDir)$(TargetName).tekniqlicense" "%TARGET_FOLDER%"

What this script does

  1. Runs the local signing tool
  2. Points the signer at the freshly built plugin DLL
  3. Generates a sidecar file next to the DLL
  4. Copies the DLL to the Tekla extension folder
  5. Copies the matching .tekniqlicense file to the same location

Expected output files

MyPluginFeature.dll
MyPluginFeature.tekniqlicense

7. Step 5 – Deploy the plugin files

The plugin DLL and the .tekniqlicense sidecar file always belong together. If one is missing, runtime validation will fail.

Where to deploy

C:\TeklaStructures\2025.0\Environments\common\extensions\Features\MyPlugin\

What must be in that folder

MyPluginFeature.dll
MyPluginFeature.tekniqlicense
Any additional plugin dependencies
Any required UI or resource files
Rule: never deploy the DLL without its matching sidecar file.

8. Step 6 – Verify that everything works

Positive test

  1. Build the plugin
  2. Confirm that the .tekniqlicense file was generated
  3. Confirm that both files were copied to the Tekla extension folder
  4. Start Tekla and load the plugin
  5. Confirm that initialization succeeds and the plugin runs normally

Failure tests

  • Delete the sidecar file and confirm startup fails
  • Change the developer GUID and rebuild only the DLL, then confirm validation fails
  • Reuse a sidecar from another DLL and confirm hash validation fails
  • Modify the plugin DLL after signing and confirm validation fails

9. Recommended project structure

A simple structure like this keeps the integration clear and maintainable:

MyPlugin/
├─ Features/
│  └─ MyPluginFeature.cs
├─ Licensing/
│  └─ TekniqDeveloperInfo.cs
├─ Tools/
│  └─ TekniqSignLocal.exe
├─ References/
│  └─ TekniqSDK.dll
├─ Properties/
│  └─ AssemblyInfo.cs
└─ MyPlugin.csproj

10. Commands and snippets

A. Assembly attribute snippet

using TekniqSDK.Licensing;

[assembly: TekniqDeveloper("YOUR-DEVELOPER-GUID-HERE")]

B. Initialization snippet

TekniqSdk.Initialize(typeof(StartUpFeature).Assembly);
TekniqSdk.RequireInitialized();
TekniqSdk.RequireLicensed();

C. Example sidecar file shape

{
  "DeveloperId": "2cc4ae73-1da8-458d-a64a-2b3f671f7e8f",
  "Email": "developer@example.com",
  "LicenseId": "LOCAL-TEST-001",
  "Module": "TekniqSDK",
  "IssuedUtc": "2026-03-08T10:00:00Z",
  "ExpiresUtc": "2030-01-01T00:00:00Z",
  "DllSha256": "...",
  "Signature": "LOCAL-TEST"
}

D. Build event example

echo START TEKNIQ SIGN LOCAL
"$(ProjectDir)Tools\TekniqSignLocal.exe" --dll "$(TargetPath)" --email "developer@example.com" --module "TekniqSDK"
echo END TEKNIQ SIGN LOCAL

11. Common errors

Problem Likely cause What to do
Plugin fails during startup TekniqSdk.Initialize(...) is missing or runs too late Move initialization to the earliest practical startup point
No .tekniqlicense file is generated Post-build command is wrong or the signer path is incorrect Verify the tool path and test the command manually
License mismatch The assembly GUID does not match the sidecar Use the correct developer GUID and regenerate the sidecar
Hash mismatch The DLL changed after signing Rebuild and rerun the signer so the sidecar matches the final DLL
Everything builds, but Tekla cannot run it The DLL was copied without the sidecar file or to the wrong folder Confirm the deployment path and confirm that both files are present

12. FAQ

Do I need to edit the sidecar file manually?

No. The sidecar file should be generated by the signing tool. Manual edits will usually invalidate the file.

Can I change my developer GUID later?

Only if Tekniq gives you a new one. If the GUID changes, your plugin must be rebuilt and resigned.

Can I deploy only the DLL in a package?

No. The package must contain both the plugin DLL and the matching .tekniqlicense file.

Why does the signer read the assembly metadata instead of loading the plugin?

Because directly loading the plugin assembly in a signing tool can fail when Tekla-specific dependencies are not available in that process.

13. Final checklist

  1. TekniqSDK.dll is referenced
  2. The assembly contains [assembly: TekniqDeveloper("...")]
  3. TekniqSdk.Initialize(typeof(YourPluginClass).Assembly) is called during startup
  4. The post-build signer runs successfully
  5. The .tekniqlicense file is generated
  6. Both the DLL and sidecar file are copied to the Tekla extension folder
  7. The plugin starts successfully inside Tekla
Developer rule of thumb: every time the DLL changes, make sure the sidecar is regenerated and redeployed together with it.