11-02-2026, 09:54 AM
StaadPro.Interop: a C# foundation for repeatable STAAD.Pro automation
StaadPro.Interop is an independent, open-source .NET wrapper around Bentley STAAD.Pro's OpenSTAAD automation interface. The project is authored by Srinivasa Rao Masanam and is now published under StruXllence. Its purpose is to help engineers build maintainable C# applications around STAAD models using typed interfaces, structural entities, documented contracts and managed results.
Repository: github.com/StruXllence/StaadPro.Interop
Documentation: API reference | Installation and session lifecycle | Release notes
1. Why use a typed wrapper?
OpenSTAAD lets external programs interact with STAAD.Pro. In a larger engineering application, the difficult work extends beyond calling an automation method: identifying the correct running model, distinguishing IDs from array indices, interpreting native return values, preserving units and axes, handling incomplete native output, and coordinating operations on a shared COM session.
StaadPro.Interop provides a managed layer for those responsibilities. It exposes separate adapters and interfaces for related API areas, together with documented input and output models. This can make automation easier to discover in IntelliSense, review in code and exercise with repeatable tests. It does not replace STAAD.Pro's analysis engine or turn an unverified calculation into an accepted engineering result.
2. Main areas of the API
3. Runtime requirements
Live interoperability requires Windows, a consumer targeting .NET Framework 4.8.1, and a separately installed/licensed STAAD.Pro version exposing the APIs being used. The .NET SDK used to build a project is not the same thing as its target framework. This main package should not be treated as a general .NET 8 or cross-platform library.
An open model and an appropriate COM apartment are required for model operations. Keep acquisition and subsequent calls on the application's established STA thread; serialize access to the same STAAD session. Moving calls to Task.Run does not automatically make COM access safe.
4. A small read-only starting point
With an appropriate package/project reference in a Windows net481 console application, open a STAAD model and start by reading its identity:
Confirm the returned model before adding geometry or result queries. Acquiring an instance is not proof that an analysis has completed or that its results are current. Saving, closing, reloading and analyzing models remain explicit operations with potential side effects.
5. Build from source and contribute
Use a suitable Windows development environment and the repository's current setup instructions. Offline managed tests can run without Bentley binaries; live integration work needs licensed STAAD.Pro. Managed test coverage and packaged XML examples are evidence about the wrapper, not certification of every native STAAD build or engineering convention.
Useful contributions include minimal reproducible issues, clearer method contracts, controlled examples and regression tests. For a defect, report the package version or source commit, STAAD version, target framework, exact method, units, expected result and observed result. Use a small nonconfidential model where possible. Do not upload client/project files without permission.
6. Source versus published package
The main branch can contain work that is not yet available on NuGet. As checked on 2 November 2026, 1.0.0-preview.20261102.1 is listed in the public package feed and its archive is downloadable. The main branch can still move ahead of a published release. Pin the exact version or commit when reproducing a workflow. The companion NuGet thread explains installation of the verified public release.
License and independence
The current repository declares Apache License 2.0 and includes attribution/legacy notices. Earlier published archives retain the terms shipped with those archives; consult the exact revision and package notices. This is an independent project, not a Bentley-endorsed or Bentley-supported product. STAAD.Pro/OpenSTAAD and other referenced names belong to their respective owners, and no Bentley license or proprietary binaries are included.
Discussion: Which repeated engineering task would you like to automate first: geometry checking, load auditing, result extraction or reporting? Describe the workflow and the checks you would need before relying on it.
StaadPro.Interop is an independent, open-source .NET wrapper around Bentley STAAD.Pro's OpenSTAAD automation interface. The project is authored by Srinivasa Rao Masanam and is now published under StruXllence. Its purpose is to help engineers build maintainable C# applications around STAAD models using typed interfaces, structural entities, documented contracts and managed results.
Repository: github.com/StruXllence/StaadPro.Interop
Documentation: API reference | Installation and session lifecycle | Release notes
1. Why use a typed wrapper?
OpenSTAAD lets external programs interact with STAAD.Pro. In a larger engineering application, the difficult work extends beyond calling an automation method: identifying the correct running model, distinguishing IDs from array indices, interpreting native return values, preserving units and axes, handling incomplete native output, and coordinating operations on a shared COM session.
StaadPro.Interop provides a managed layer for those responsibilities. It exposes separate adapters and interfaces for related API areas, together with documented input and output models. This can make automation easier to discover in IntelliSense, review in code and exercise with repeatable tests. It does not replace STAAD.Pro's analysis engine or turn an unverified calculation into an accepted engineering result.
2. Main areas of the API
- Connection and Root: acquire an existing STAAD session, inspect model identity and units, and explicitly request model/application operations.
- Geometry: work with nodes, beams, plates, connectivity and groups. Read the method contracts before using creation, merge or mesh operations.
- Load: inspect primary/reference/combination cases, assignments and metadata, and build selected load-definition workflows.
- Property: inspect materials, member sections and specifications, with version-aware contracts and separately acquired catalog capabilities where applicable.
- Output: retrieve supported analysis/design observations through named managed results. Check result status before consuming data, and verify axes, signs and units.
- Support, Commands and Design: support definitions/assignments, analysis-command configuration and supported design-brief/query workflows.
- Table and View: supported report-table operations and graphical orientation requests. Coverage is evolving; use the exact version's documentation rather than assuming every OpenSTAAD operation is implemented.
3. Runtime requirements
Live interoperability requires Windows, a consumer targeting .NET Framework 4.8.1, and a separately installed/licensed STAAD.Pro version exposing the APIs being used. The .NET SDK used to build a project is not the same thing as its target framework. This main package should not be treated as a general .NET 8 or cross-platform library.
An open model and an appropriate COM apartment are required for model operations. Keep acquisition and subsequent calls on the application's established STA thread; serialize access to the same STAAD session. Moving calls to Task.Run does not automatically make COM access safe.
4. A small read-only starting point
With an appropriate package/project reference in a Windows net481 console application, open a STAAD model and start by reading its identity:
Code:
using System;
using StaadPro.Interop.Services;
internal static class Program
{
[STAThread]
private static void Main()
{
using (var wrapper = OpenStaadWrapperProvider.GetRunning())
{
if (wrapper == null)
{
Console.WriteLine("Open a usable STAAD.Pro session first.");
return;
}
Console.WriteLine(wrapper.Root.GetStaadFileFullPath());
}
}
}Confirm the returned model before adding geometry or result queries. Acquiring an instance is not proof that an analysis has completed or that its results are current. Saving, closing, reloading and analyzing models remain explicit operations with potential side effects.
5. Build from source and contribute
Code:
git clone https://github.com/StruXllence/StaadPro.Interop.git
cd StaadPro.Interop
dotnet build StaadPro.Interop.sln -c Release
dotnet test tests/StaadPro.Interop.Tests/StaadPro.Interop.Tests.csproj -c Release --no-buildUse a suitable Windows development environment and the repository's current setup instructions. Offline managed tests can run without Bentley binaries; live integration work needs licensed STAAD.Pro. Managed test coverage and packaged XML examples are evidence about the wrapper, not certification of every native STAAD build or engineering convention.
Useful contributions include minimal reproducible issues, clearer method contracts, controlled examples and regression tests. For a defect, report the package version or source commit, STAAD version, target framework, exact method, units, expected result and observed result. Use a small nonconfidential model where possible. Do not upload client/project files without permission.
6. Source versus published package
The main branch can contain work that is not yet available on NuGet. As checked on 2 November 2026, 1.0.0-preview.20261102.1 is listed in the public package feed and its archive is downloadable. The main branch can still move ahead of a published release. Pin the exact version or commit when reproducing a workflow. The companion NuGet thread explains installation of the verified public release.
License and independence
The current repository declares Apache License 2.0 and includes attribution/legacy notices. Earlier published archives retain the terms shipped with those archives; consult the exact revision and package notices. This is an independent project, not a Bentley-endorsed or Bentley-supported product. STAAD.Pro/OpenSTAAD and other referenced names belong to their respective owners, and no Bentley license or proprietary binaries are included.
Discussion: Which repeated engineering task would you like to automate first: geometry checking, load auditing, result extraction or reporting? Describe the workflow and the checks you would need before relying on it.