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.exeduring the current testing phase - The expected Tekla extension deployment folder for your plugin
- The correct startup class or plugin entry point in your solution
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
.tekniqlicensesidecar 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
- Right-click the plugin project
- Select Add Reference
- Browse to
TekniqSDK.dll - 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")]
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.
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
- Runs the local signing tool
- Points the signer at the freshly built plugin DLL
- Generates a sidecar file next to the DLL
- Copies the DLL to the Tekla extension folder
- Copies the matching
.tekniqlicensefile 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
8. Step 6 – Verify that everything works
Positive test
- Build the plugin
- Confirm that the
.tekniqlicensefile was generated - Confirm that both files were copied to the Tekla extension folder
- Start Tekla and load the plugin
- 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
TekniqSDK.dllis referenced- The assembly contains
[assembly: TekniqDeveloper("...")] TekniqSdk.Initialize(typeof(YourPluginClass).Assembly)is called during startup- The post-build signer runs successfully
- The
.tekniqlicensefile is generated - Both the DLL and sidecar file are copied to the Tekla extension folder
- The plugin starts successfully inside Tekla