# AVEVA GRAccess DLL and .NET 10 Notes

Date: 2026-04-26

## Installed GRAccess files

Primary AVEVA/System Platform GRAccess files found on this machine:

| Path | Purpose | Runtime / architecture |
| --- | --- | --- |
| `C:\Program Files (x86)\Common Files\ArchestrA\Framework\Bin\GRAccess.dll` | Main GRAccess COM in-process server | Native PE32 x86, file version `5200.0051.1991.1` |
| `C:\Program Files (x86)\Common Files\ArchestrA\ArchestrA.GRAccess.dll` | .NET COM interop assembly | IL-only, CLR v2 metadata, assembly version `2.0.0.0`, file version `2000.0002.1957.1` |
| `C:\Windows\assembly\GAC\ArchestrA.GRAccess\2.0.0.0__23106a86e706d0ae\ArchestrA.GRAccess.dll` | GAC copy of the interop assembly | Same assembly version `2.0.0.0` |
| `C:\Program Files (x86)\ArchestrA\Framework\Bin\GRAccessApp.exe` | GRAccess COM out-of-process server | Native PE32 x86, file version `5200.0051.1991.1` |
| `C:\Program Files (x86)\Common Files\ArchestrA\GRAccess20.tlb` | Current GRAccess type library | COM metadata |

Older type libraries are also installed in:

`C:\Program Files (x86)\Common Files\ArchestrA`

Files present:

- `GRAccess10.tlb`
- `GRAccess11.tlb`
- `GRAccess111.tlb`
- `GRAccess12.tlb`
- `GRAccess13.tlb`
- `GRAccess14.tlb`
- `GRAccess15.tlb`
- `GRAccess16.tlb`
- `GRAccess17.tlb`
- `GRAccess18.tlb`
- `GRAccess19.tlb`
- `GRAccess20.tlb`

AutoBuild-related GRAccess files:

| Path | Purpose | Runtime / architecture |
| --- | --- | --- |
| `C:\Program Files (x86)\Wonderware\OI-Server\AutoBuild\Bin\ArchestrA.GRAccess.dll` | AutoBuild interop assembly | IL-only, CLR v2 metadata, assembly version `1.8.0.0` |
| `C:\Program Files (x86)\Wonderware\OI-Server\AutoBuild\Bin\GRAccessUtility.dll` | AutoBuild helper | Managed IL-only, references .NET Framework 4-era assemblies |
| `C:\Program Files (x86)\Wonderware\OI-Server\AutoBuild\Bin\GRAccessProcess.exe` | AutoBuild process helper | Managed IL-only, `32BITREQUIRED` |

## COM registration

`GRAccess` / `GRAccess.1`

- CLSID: `{40F5AD46-FE1A-4D0E-B92D-C643E8D2BDF3}`
- Registered under the 32-bit COM registry view:
  `HKLM\SOFTWARE\WOW6432Node\Classes\CLSID\{40F5AD46-FE1A-4D0E-B92D-C643E8D2BDF3}`
- In-process server:
  `C:\Program Files (x86)\Common Files\ArchestrA\Framework\Bin\GRAccess.dll`
- Threading model: `Apartment`

`GRAccessApp` / `GRAccessApp.1`

- CLSID: `{949654D1-B9C0-468f-B43D-33431004297A}`
- AppID: `{604B52A4-FD85-4F02-9C53-C61B23D2039C}`
- Local server:
  `C:\Program Files (x86)\ArchestrA\Framework\Bin\GRAccessApp.exe`
- TypeLib: `{054F998C-9E20-425C-A69D-FCEA0F44442E}`

The `GRAccessApp` type library registration points to:

`C:\Program Files (x86)\ArchestrA\Framework\Bin\GRAccessApp.exe`

## ExportObjects `TYPE_E_LIBNOTREGISTERED` finding

`IgObjects.ExportObjects(...)` can fail with:

```text
Library not registered. (Exception from HRESULT: 0x8002801D (TYPE_E_LIBNOTREGISTERED))
```

Two separate issues were verified locally:

1. .NET publisher policy redirects `ArchestrA.GRAccess` to the GAC `2.0.0.0` interop assembly unless the CLI opts out. The CLI carries and builds against the local `1.7.0.0` interop assembly, which matches the working command surface. `src/ZB.MOM.WW.GRAccess.Cli/App.config` disables publisher policy for `ArchestrA.GRAccess` so the private assembly is used.
2. Late-bound reflection calls against `IgObjects.ExportObjects` can trigger type-library lookup failures even when the typed interface call works. Export/package fallback code should call the strongly typed `IgObjects.ExportObjects(...)`, `IgObjects.ExportObjectsAsProtected(...)`, and `IgObjects.Add(...)` methods instead of using `InvokeMember`.

After both fixes, this command successfully exports `$TestMachine` from `ZB` to an `.aaPKG`:

```powershell
graccess objects export --galaxy ZB --node . --type template --name '$TestMachine' --output "$env:TEMP\TestMachine.aaPKG" --export-type exportAsPDF --confirm --confirm-target "$env:TEMP\TestMachine.aaPKG" --llm-json
```

## .NET 10 / x64 compatibility notes

The installed AVEVA GRAccess stack is not a .NET 10, full-managed, x64-compatible DLL stack.

Key findings:

- `GRAccess.dll` is native PE32 x86. It cannot be loaded into a .NET 10 x64 process.
- `ArchestrA.GRAccess.dll` is an interop assembly, not the implementation. It contains mostly `[ComImport]` interfaces/classes such as `IGRAccess`, `GRAccessClass`, and `GRAccessAppClass`.
- The interop assembly uses old CLR metadata and references `mscorlib, Version=1.0.5000.0`.
- The in-process COM class `GRAccess` is registered only in the 32-bit COM view. Creating it from 64-bit PowerShell/.NET fails with `REGDB_E_CLASSNOTREG` / `0x80040154`.
- The out-of-process COM class `GRAccessApp` can be created from a 64-bit process because COM can launch the 32-bit local server EXE.
- `GRAccessApp.exe.config` uses:

```xml
<startup useLegacyV2RuntimeActivationPolicy="true">
  <supportedRuntime version="v4.0"/>
</startup>
```

This is .NET Framework-era hosting/configuration, not .NET 10.

## Native dependency imports

`GRAccess.dll` imports these native DLLs:

```text
ADVAPI32.dll
ATL100.DLL
dbghelp.dll
KERNEL32.dll
MSVCP100.dll
MSVCR100.dll
ole32.dll
OLEAUT32.dll
Secur32.dll
SHLWAPI.dll
USER32.dll
WWPackageManager.DLL
```

`GRAccessApp.exe` imports:

```text
ADVAPI32.dll
ATL100.DLL
dbghelp.dll
KERNEL32.dll
MSVCP100.dll
MSVCR100.dll
ole32.dll
OLEAUT32.dll
SHLWAPI.dll
USER32.dll
```

## Practical options for a new .NET 10 project

For a .NET 10 x64 project, there are three realistic approaches:

1. Use `GRAccessApp` as an out-of-process COM bridge if its exposed API covers the required operations.
2. Build a 32-bit sidecar process that loads the native GRAccess COM stack, then expose a modern IPC API to .NET 10 x64.
3. Reimplement the needed GRAccess behavior in managed .NET 10 x64 using the type libraries and observed behavior as reference material.

Do not plan on directly referencing `GRAccess.dll` from .NET 10 x64. It is a 32-bit native COM server.