UnmanagedCallersOnly属性

static メソッドに付与すると、そのメソッドをネイティブコードから直接呼び出せるCのエントリポイントとして公開できる.NETの属性。

概念URI

https://comcomponent.com/knowledge/unmanagedcallersonly/

別名・表記

UnmanagedCallersOnlyAttribute

上位概念

Native AOT

最終確認日

2026-08-01

機械可読データ

JSON-LD

この概念が関わる関係

• Native AOTはUnmanagedCallersOnly属性を利用します。Native AOTで発行するC#のクラスライブラリは、UnmanagedCallersOnlyを付けたメソッドをCのエントリポイントとして公開できる。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• UnmanagedCallersOnly属性はblittable型を前提とします。UnmanagedCallersOnlyを付けたメソッドのシグネチャには、blittableな型しか使えない。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 呼び出し規約(calling convention)はUnmanagedCallersOnly属性で構成できます。呼び出し規約はUnmanagedCallersOnlyのCallConvsパラメーターで、cdeclなどを明示的に固定できる。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• UnmanagedCallersOnly属性はC ABI(Application Binary Interface)を前提とします。exportされるのはあくまでCの関数入口であり、境界面は.NETではなくC ABIとして設計する必要がある。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• エラーをstatus codeで返す設計はUnmanagedCallersOnly属性に対する本記事の推奨です。managed例外をそのまま呼び出し元へ漏らさず、戻り値をstatus code、実データをoutポインタ引数で返す設計が、UnmanagedCallersOnlyの境界では実務上推奨される。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• ハンドルベースのC API設計(create/destroy/operate)はUnmanagedCallersOnly属性に対する本記事の推奨です。create/destroy/operateのようなフラットなC APIに落として寿命管理とエラーコードを明示する設計が、UnmanagedCallersOnlyの境界では実務上安定する。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• UnmanagedCallersOnly属性は関数ポインターのデリゲートがGCに回収されるクラッシュに対する本記事の推奨です。delegate型よりUnmanagedCallersOnlyを付けた静的メソッドと関数ポインターを使うことが、オーバーヘッドの小さい代替として推奨される / 確度: 確立した関係 / 確認日: 2026-08-01 出典

この概念を扱う記事

• C# Native AOT DLLをC/C++から呼び出す方法(主要トピック)
• C#からWin32 APIを安全に呼ぶ ── P/Invoke実務ガイド(DllImport / LibraryImport / CsWin32)(言及)

一次資料

• https://learn.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.unmanagedcallersonlyattribute?view=net-10.0

このページはサイトの知識グラフ(_data/knowledge/)から自動生成されています。誤りの指摘はお問い合わせからお願いします。