C#からネイティブDLLを呼ぶ：C++/CLIラッパー vs P/Invoke

Windows の既存資産や既存 DLL を C# から使いたい、という要件はかなりよくあります。 相手が Win32 API のような素直な C インターフェースなら、P/Invoke で十分です。

ただ、実務で出てくるのはもっと癖のある DLL です。 C++ のクラスがあり、所有権の流儀があり、例外も飛び、std::wstring や std::vector も普通に出てきます。 ここで P/Invoke だけで押し切ると、たいてい境界面がだんだん苦しくなります。

この記事では、そういうときに C++/CLI で薄いラッパーを 1 枚挟む と何が楽になるのかを書いていきます。 P/Invoke が悪いという話ではなく、P/Invoke で十分な場面と C++/CLI が効く場面は違う、というのが趣旨です。

なお、この記事に登場するコード抜粋は、ビルドできるサンプル一式（ネイティブ C++ ライブラリ、C API ブリッジ、C++/CLI ラッパー、P/Invoke 版と C++/CLI 版の C# 消費コード）として GitHub で公開しています。

cpp-cli-wrapper-for-native-dlls - komurasoft-blog-samples (GitHub)

対象読者と前提

C# からネイティブ DLL を呼んだことがあり、DllImport の宣言までは書けるけれど、相手が C++ のクラスライブラリになったところで手が止まっている開発者 に向けて書いています。C++/CLI そのものは未経験でかまいません。逆に、P/Invoke をまだ書いたことがないなら、先に「C#からWin32 APIを安全に呼ぶ ── P/Invoke実務ガイド」を読んでからのほうが早いです。

想定環境は Windows + Visual Studio 2022 で、C++/CLI ラッパー（.vcxproj）と C# プロジェクトを同じソリューションに置ける構成です。ターゲットは .NET Framework でも .NET 8 などでもかまいませんが、.NET 側には固有の制約があるので 7 章にまとめてあります。

先に押さえておく用語

目次

1. まず結論（ひとことで）
2. P/Invoke で十分なケース
3. P/Invoke が急にしんどくなる境界
4. C++/CLI ラッパーを挟む構成
5. C++/CLI で何が楽になるのか
6. コード抜粋
7. それでも C++/CLI を選ばないほうがよいケース
8. まとめ
9. 参考資料

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全21件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

1. まず結論（ひとことで）

• 相手が C の関数群なら、P/Invoke が素直
• 相手が C++ のライブラリなら、C++/CLI ラッパーを 1 枚挟むと保守しやすい
• 特に クラス・所有権・文字列・配列・例外・コールバック が絡むなら、C# 側に無理をさせないほうがよい

要するに、C# にネイティブ DLL の都合を直接持ち込まない ということです。 ネイティブの都合は C++ 側で受けて、.NET に見せる面だけを整える。 この分業がうまくいくと、コードもデバッグもかなり穏やかになります。

flowchart TB
    accTitle: 相手のDLLの形で決まる使い分け
    accDescr: 相手がCの関数群ならP/Invokeが素直で、C++のライブラリならC++/CLIラッパーを1枚挟むと保守しやすいという、この記事の結論を分岐で示す。
    q{"相手のDLLはどちらか"}
    q -->|"Cの関数群"| pi["P/Invokeが素直"]
    q -->|"C++のライブラリ"| cli["C++/CLIラッパーを挟む"]
    cli -.-> note["ネイティブの都合はC++側で受ける"]

図1: 使い分けの結論。相手がCの関数群ならP/Invoke、C++のライブラリならC++/CLIラッパー。

2. P/Invoke で十分なケース

P/Invoke で片付くなら、それがいちばん簡単です。無理に C++/CLI を持ち込む必要はありません。

P/Invoke が向いているのは、たとえばこんなケースです。

• extern "C" で公開されたフラットな関数 API になっている
• 引数や戻り値が、整数・ポインタ・単純な構造体などで済む
• 文字列の規約が明確で、バッファの責務も単純
• リソース管理が Create / Destroy のように分かりやすい
• C# 側で SafeHandle や StructLayout を素直に書ける

このくらい整っているなら、C# 側で宣言して使うだけで済みますし、Windows API を呼ぶ感覚に近いので実装も読みやすくなります。

flowchart TB
    accTitle: P/Invokeで十分と判断できる条件
    accDescr: フラットなC API、単純な引数と戻り値、明確な文字列とリソースの規約という条件がそろっていれば、C#側で宣言して使うだけで済むことを示す。
    c1["extern Cのフラットな関数API"] --> ok["P/Invokeで十分"]
    c2["引数・戻り値が単純"] --> ok
    c3["文字列・リソースの規約が明確"] --> ok
    ok --> use["C#側で宣言して使うだけ"]

図2: 相手のAPIがこのくらい整っているなら、無理にC++/CLIを持ち込む必要はない。

3. P/Invoke が急にしんどくなる境界

問題は、相手が「ただの C API」ではないときです。 ここから急に空気が変わります。

3.1. C++ のクラスを相手にし始めたとき

ネイティブ DLL が C++ のクラス中心で設計されている場合、本当はクラスのメソッドをそのまま呼びたいわけですが、P/Invoke で直接相手にできるのは DLL のエクスポート関数 です。 つまり、結局どこかで C 形式の関数に落とす層 が必要になります。

この時点で、やっていることはほぼ「ラッパーを書く」です。 だったら、C# 側に IntPtr と解放関数を大量に生やすより、C++ 側にラッパーを寄せたほうが自然 です。

flowchart TB
    accTitle: C++クラス相手にP/Invokeを選んだときの帰結
    accDescr: C++のクラスのメソッドを呼びたくてもP/Invokeで相手にできるのはDLLのエクスポート関数だけなので、C形式に落とす層が必要になり、実質的にラッパーを書くことになるという流れを示す。
    want["C++クラスのメソッドを呼びたい"] --> limit["呼べるのはエクスポート関数だけ"]
    limit --> bridge["C形式の関数に落とす層が必要"]
    bridge --> fact["やっていることはほぼラッパー"]
    fact -.-> better["ならC++側に寄せるほうが自然"]

図3: P/Invokeで押し切ろうとしても、C++クラスが相手だと結局どこかでラッパーを書くことになる。

3.2. 所有権と寿命管理が見えにくいとき

C++ では、

• 呼び出し側が解放するのか
• 返されたポインタは借り物なのか
• const& なのか所有権移動なのか
• 内部でキャッシュしていて寿命に前提があるのか

といった話が普通にあります。

これを C# の IntPtr ベースで表現すると、最初は動いても、後で読み返したときにかなりつらいです。 「このポインタ、誰がいつ消すんだっけ問題」が始まると、境界面はすぐ濁ります。

flowchart TB
    accTitle: 所有権の前提をIntPtrで表現したときの濁り方
    accDescr: 誰が解放するのか、借り物か所有権移動か、寿命に前提があるのかというC++側の事情をC#のIntPtrベースで表現すると、後で読み返したときにつらくなり境界面が濁ることを示す。
    q1["誰が解放するのか"] --> ptr["C#のIntPtrで表現する"]
    q2["借り物か所有権移動か"] --> ptr
    q3["寿命に前提があるか"] --> ptr
    ptr --> bad["最初は動いても後で読めない"]
    bad --> muddy["境界面がすぐ濁る"]

図4: 所有権と寿命の前提をIntPtrベースで持ち回ると、「誰がいつ消すんだっけ問題」で境界面が濁る。

3.3. std::wstring、std::vector、コールバック、例外が出てきたとき

この辺から、P/Invoke は「書けなくはないが、気持ちよくはない」領域に入ります。

• std::wstring をそのまま C# から表したい
• std::vector<T> を返したい
• ネイティブ処理の進捗をコールバックで受けたい
• 失敗時に C++ 例外が飛ぶ

こういう要素が増えると、C# 側に MarshalAs、手動バッファ、固定長配列、デリゲート寿命管理、エラーコード解釈などが増えてきます。

もちろん頑張れば書けます。 ただ、がんばりどころが本質ではない のがつらいところです。 本来やりたいのは業務ロジックや UI であって、境界面の格闘技ではありません。

flowchart TB
    accTitle: C++要素の増加とC#側の負担の積み上がり
    accDescr: wstringやvectorを返したい、コールバックで進捗を受けたい、C++例外が飛ぶといった要素が増えるほど、C#側にMarshalAsや手動バッファ、デリゲート寿命管理が積み上がることを示す。
    e1["wstringやvectorを返したい"] --> pile["C#側の記述が積み上がる"]
    e2["コールバックで進捗を受けたい"] --> pile
    e3["失敗時にC++例外が飛ぶ"] --> pile
    pile --> load["MarshalAs・手動バッファ"]
    pile --> load2["デリゲート寿命管理・エラー解釈"]

図5: C++らしい要素が増えるたびに、C#側の境界コードの負担が積み上がっていく。

3.4. C++ の都合を C# に漏らしたくないとき

ネイティブ DLL 側の API がそのまま C# に向いているとは限りません。

たとえばネイティブ側では、

• 複数のメソッド呼び出しを組み合わせて 1 回の処理にする
• エラーは戻り値と out 引数で返す
• 初期化順序に前提がある
• スレッドセーフ性に制約がある

という設計でも、C# 側にはもっと素直な API を見せたいことが多いです。 ここを変換する層として、C++/CLI はかなり都合がよいです。

flowchart TB
    accTitle: ネイティブの都合を変換してC#に見せる層
    accDescr: 初期化順序やスレッドセーフ性の制約などネイティブAPIの設計の都合を、C++/CLIの変換層で受け止めて、C#側にはもっと素直なAPIを見せるという役割分担を示す。
    nat["ネイティブAPIの設計の都合"] -.-> ex["初期化順序・スレッド制約など"]
    nat --> conv["C++/CLIの変換層"]
    conv --> api["C#には素直なAPIを見せる"]

図6: ネイティブ側の設計の都合をそのままC#に向けず、C++/CLIを変換する層として挟む。

4. C++/CLI ラッパーを挟む構成

構成としてはシンプルです。

flowchart LR
    Cs[C# アプリ] -->|.NET 向けの API| Wrapper[C++/CLI ラッパー DLL]
    Wrapper -->|ネイティブのヘッダーや型を直接扱う| Native[ネイティブ C++ DLL]

図7: C#アプリとネイティブC++ DLLの間に、C++/CLIラッパーDLLを1枚挟む構成。

C# から見えるのは .NET らしい API だけにして、

• 文字列変換
• 配列やベクターの変換
• 例外の変換
• 所有権の整理
• エラーコードの解釈
• 必要ならスレッド境界やコールバックの吸収

を C++/CLI 側に閉じ込めます。

大事なのは、C++/CLI プロジェクト自体を大きくしすぎない ことです。 役割はあくまで「翻訳」と「整形」です。 業務ロジックまで入れ始めると、今度はその層が主役になってしまいます。

flowchart TB
    accTitle: C++/CLIラッパーに閉じ込める仕事
    accDescr: 文字列や配列の変換、例外とエラーコードの変換、所有権の整理といった翻訳と整形の仕事をC++/CLI側に閉じ込め、業務ロジックは入れないという役割の線引きを示す。
    w["C++/CLIラッパーの役割"] --> t1["文字列・配列の変換"]
    w --> t2["例外・エラーコードの変換"]
    w --> t3["所有権の整理"]
    w -.-> warn["業務ロジックは入れない"]

図8: ラッパーの役割は「翻訳」と「整形」に限定し、大きくしすぎないのが大事。

5. C++/CLI で何が楽になるのか

5.1. C++ の型を C++ のまま扱える

これはかなり大きいです。 C++/CLI 側ではネイティブのヘッダーをインクルードして、そのまま C++ の型を使えます。

つまり、C# 側で無理に「C++ の世界を再現」しなくて済みます。 std::wstring も std::vector も、まずは C++ の型として受け止めてから、必要な形で .NET 側に渡せばよいです。

flowchart TB
    accTitle: C++の型を受け止めてから.NETへ渡す流れ
    accDescr: ネイティブのヘッダーをインクルードしてwstringやvectorをC++の型のまま受け止め、必要な形に変換してから.NET側へ渡すことで、C#側でC++の世界を再現しなくて済むことを示す。
    nt["ネイティブのwstringやvector"] --> recv["C++/CLI側でC++の型のまま受ける"]
    recv --> conv["必要な形へ変換する"]
    conv --> net[".NET側へ渡す"]
    net -.-> nofake["C#でC++の世界を再現しない"]

図9: C++の型はいったんC++の型として受け止め、変換してから.NETに渡せばよい。

5.2. API を .NET 向けに整形できる

C# 側には、

• string
• byte[]
• List<T>
• IDisposable
• 例外

といった、見慣れた形で API を出せます。

この差は地味に見えて、使う側の負担を大きく変えます。 特にチーム開発だと、ネイティブ事情を知らないメンバーでも触りやすくなるのが効きます。

5.3. 例外とエラーの責務を整理しやすい

ネイティブ側で例外やエラーコードが混在していると、C# 側でそのまま受けるのは扱いづらいです。 C++/CLI 側で一度まとめて、

• 例外は .NET の例外へ変換する
• エラーコードは意味のある例外や結果型に変換する
• ログに必要な文脈を補う

といったことができます。

境界で一度「意味のある失敗」に翻訳しておくと、呼び出し側はかなりすっきりします。

flowchart TB
    accTitle: 例外とエラーコードの境界での翻訳
    accDescr: ネイティブ側で混在する例外とエラーコードをC++/CLI側で一度まとめ、例外は.NETの例外へ、エラーコードは意味のある例外や結果型へ変換し、ログに必要な文脈を補うことを示す。
    mixed["ネイティブの例外とエラーコード"] --> tr["C++/CLI側で一度まとめる"]
    tr --> e1["例外は.NETの例外へ変換"]
    tr --> e2["エラーコードは意味のある形へ変換"]
    tr -.-> log["ログに必要な文脈を補う"]

図10: 境界で一度「意味のある失敗」に翻訳しておくと、C#の呼び出し側がすっきりする。

5.4. ABI の揺れを C# 側から隠せる

C++ のクラスやメソッドは、C の関数のように単純な ABI ではありません。 C# が直接その事情を知り始めると、エクスポート関数やマーシャリングの都合が表に出てきます。

C++/CLI ラッパーを挟めば、C++ の都合は C++ 側に閉じ込めて、C# には安定した面だけを見せる ことができます。 この分離は、ライブラリ更新時にも効きます。

flowchart TB
    accTitle: ABIの揺れをラッパーで遮る構図
    accDescr: C++のクラスやメソッドはCの関数のように単純なABIではないため、その事情をC++側に閉じ込め、C#には安定した面だけを見せると、ライブラリ更新時にも分離が効くことを示す。
    abi["C++クラスのABIは単純でない"] --> hide["C++の都合はC++側に閉じ込める"]
    hide --> stable["C#には安定した面だけを見せる"]
    stable -.-> update["ライブラリ更新時にも効く分離"]

図11: マーシャリングやエクスポート関数の都合を表に出さず、C#には安定した面だけを見せる。

5.5. 段階的移行がしやすい

既存のネイティブ DLL をいきなり全部作り直すのは重いです。 C++/CLI ラッパーなら、まずは必要な API だけ薄く包み、C# 側の新しい画面やワークフローから使い始める、という段階的な移行がしやすいです。

Windows の既存資産を活かしながら周辺を .NET に寄せる、という場面ではかなり相性がよいです。

6. コード抜粋

ここでは「そのまま動く完全なサンプル」ではなく、境界面のイメージが分かる程度の抜粋だけ載せます。

6.1. ネイティブ DLL 側の API イメージ

// NativeLib.hpp
#pragma once
#include <string>
#include <vector>

namespace NativeLib
{
    struct AnalyzeOptions
    {
        int threshold;
        std::wstring modelPath;
    };

    struct AnalyzeResult
    {
        bool ok;
        std::wstring message;
        std::vector<int> scores;
    };

    class Analyzer
    {
    public:
        explicit Analyzer(const std::wstring& licensePath);
        AnalyzeResult Analyze(const std::wstring& imagePath, const AnalyzeOptions& options);
    };
}

この API は、ネイティブ C++ としては普通です。 でも C# からそのまま触るには、なかなか骨があります。

6.2. P/Invoke でやろうとするとこうなる

まず、C# から直接呼ぶためには、どこかで C 形式の関数 に落とす必要があります。 たとえばこんなブリッジ関数を別途用意することになります。

// C API に落としたブリッジのイメージ
extern "C"
{
    __declspec(dllexport) void* Analyzer_Create(const wchar_t* licensePath);
    __declspec(dllexport) void  Analyzer_Destroy(void* handle);

    __declspec(dllexport) int Analyzer_Analyze(
        void* handle,
        const wchar_t* imagePath,
        const AnalyzeOptionsNative* options,
        AnalyzeResultNative* result);
}

C# 側も、こんな雰囲気になります。

internal sealed class SafeAnalyzerHandle : SafeHandle
{
    private SafeAnalyzerHandle() : base(IntPtr.Zero, ownsHandle: true) { }

    public override bool IsInvalid => handle == IntPtr.Zero;

    protected override bool ReleaseHandle()
    {
        NativeMethods.Analyzer_Destroy(handle);
        return true;
    }
}

[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Unicode)]
internal struct AnalyzeOptionsNative
{
    public int Threshold;
    public IntPtr ModelPath;
}

internal static class NativeMethods
{
    [DllImport("NativeBridge.dll", CharSet = CharSet.Unicode)]
    internal static extern SafeAnalyzerHandle Analyzer_Create(string licensePath);

    [DllImport("NativeBridge.dll", CharSet = CharSet.Unicode)]
    internal static extern void Analyzer_Destroy(IntPtr handle);

    [DllImport("NativeBridge.dll", CharSet = CharSet.Unicode)]
    internal static extern int Analyzer_Analyze(
        SafeAnalyzerHandle handle,
        string imagePath,
        ref AnalyzeOptionsNative options,
        out AnalyzeResultNative result);
}

これで済むならよいのですが、実際にはさらに

• 可変長データをどう返すか
• 文字列バッファを誰が解放するか
• エラー詳細をどこに置くか
• コールバック寿命をどう守るか

といった論点が増えてきます。

つまり、P/Invoke を選んだつもりが、実質的には C 互換 API の設計を始めている ことが多いです。

flowchart TB
    accTitle: P/Invoke案が実質C互換API設計になる流れ
    accDescr: P/Invokeで直接呼ぶつもりでも、Cブリッジ関数を用意し、C#側にSafeHandleやStructLayoutを書き、可変長データや解放やコールバックの論点が増えて、実質的にC互換APIの設計を始めていることになる流れを示す。
    start["P/Invokeで直接呼ぶつもり"] --> bridge["Cブリッジ関数を別途用意"]
    bridge --> decl["SafeHandleやStructLayoutを書く"]
    decl --> more["可変長・解放・コールバックの論点"]
    more --> real["実質C互換APIの設計が始まる"]

図12: 「P/Invokeを選んだだけ」のつもりが、気づけばC互換APIの設計をしていることが多い。

これらの論点は、C++/CLI に寄せると次のように置き換わります。魔法のように消えるわけではなく、C++ 側で自然に書ける形に移る、というのが正確な言い方です。

6.3. C++/CLI ラッパーだとこう書ける

C++/CLI 側で、ネイティブの都合を受け止めて、C# に見せる API を整えます。

// AnalyzerWrapper.h
#pragma once
#include "NativeLib.hpp"

using namespace System;
using namespace System::Collections::Generic;

public ref class AnalysisOptions
{
public:
    property int Threshold;
    property String^ ModelPath;
};

public ref class AnalysisResult
{
public:
    property bool Ok;
    property String^ Message;
    property List<int>^ Scores;
};

public ref class AnalyzerWrapper : IDisposable
{
public:
    AnalyzerWrapper(String^ licensePath);
    ~AnalyzerWrapper();
    !AnalyzerWrapper();

    AnalysisResult^ Analyze(String^ imagePath, AnalysisOptions^ options);

private:
    NativeLib::Analyzer* _native;
};

ここで C++/CLI 特有なのが ~AnalyzerWrapper() と !AnalyzerWrapper() の 2 つです。どちらも C++ のデストラクターに見えますが、役割は .NET の Dispose パターンに対応しています。

定石は、ネイティブ資源の解放はファイナライザーに書き、デストラクターからそれを呼ぶ ことです。次の実装で ~AnalyzerWrapper() が this->!AnalyzerWrapper() を呼ぶだけになっているのがそれで、こう書いておくと C# 側が Dispose() を呼び忘れても、最後は GC が拾ってくれます。デストラクターが呼ばれた場合は GC::SuppressFinalize によってファイナライズが抑制されるため、二重解放にはなりません。

なお Dispose()、Finalize()、Dispose(bool) はコンパイラーが生成するので、C++/CLI 側で自分では書きません。逆に C++/CLI のコードから Dispose() を直接呼ぶこともできず、delete 演算子でデストラクターを呼びます。この対応関係は How to: Define and consume classes and structs (C++/CLI) - Microsoft Learn の「Destructors and finalizers」にまとまっています。

flowchart TB
    accTitle: デストラクターとファイナライザーの分担
    accDescr: C#のusingやDisposeからはデストラクターが呼ばれてファイナライザー経由でネイティブ資源を解放し、Dispose忘れの場合はGCがファイナライザーを呼んで最後は拾われ、SuppressFinalizeで二重解放が防がれることを示す。
    us["C#のusingやDispose"] --> dtor["デストラクター（Dispose相当）"]
    forget["Disposeの呼び忘れ"] -.-> gc["GC回収時にファイナライザー"]
    dtor --> fin["ファイナライザーを呼ぶ"]
    fin --> del["ネイティブ資源をdelete"]
    gc -.-> del
    dtor -.-> sup["SuppressFinalizeで二重解放を防ぐ"]

図13: 解放はファイナライザーに書き、デストラクターからそれを呼ぶ定石。Dispose忘れでも最後はGCが拾う。

// AnalyzerWrapper.cpp
#include "AnalyzerWrapper.h"
#include <msclr/marshal_cppstd.h>

using msclr::interop::marshal_as;

AnalyzerWrapper::AnalyzerWrapper(String^ licensePath)
{
    _native = new NativeLib::Analyzer(marshal_as<std::wstring>(licensePath));
}

AnalyzerWrapper::~AnalyzerWrapper()
{
    this->!AnalyzerWrapper();
}

AnalyzerWrapper::!AnalyzerWrapper()
{
    delete _native;
    _native = nullptr;
}

AnalysisResult^ AnalyzerWrapper::Analyze(String^ imagePath, AnalysisOptions^ options)
{
    // 破棄後に呼ばれたら、ネイティブへ入る前にここで止める。
    // デストラクター(= Dispose)は _native を nullptr にしているので、
    // この検査が無いと null ポインター経由でネイティブに入り、
    // .NET の例外ではなくアクセス違反でプロセスごと落ちる。
    // C# 側から見れば「Dispose 後に触ったら ObjectDisposedException」が
    // 期待される振る舞いで、_native を使うメソッドすべてに要る
    if (_native == nullptr)
    {
        throw gcnew ObjectDisposedException("AnalyzerWrapper");
    }

    NativeLib::AnalyzeOptions nativeOptions{};
    nativeOptions.threshold = options->Threshold;
    nativeOptions.modelPath = marshal_as<std::wstring>(options->ModelPath);

    try
    {
        auto nativeResult = _native->Analyze(
            marshal_as<std::wstring>(imagePath),
            nativeOptions);

        auto managed = gcnew AnalysisResult();
        managed->Ok = nativeResult.ok;
        managed->Message = gcnew String(nativeResult.message.c_str());
        managed->Scores = gcnew List<int>();

        for (int score : nativeResult.scores)
        {
            managed->Scores->Add(score);
        }

        return managed;
    }
    catch (const std::exception& ex)
    {
        throw gcnew InvalidOperationException(gcnew String(ex.what()));
    }
}

C# 側はかなり素直になります。

using var analyzer = new AnalyzerWrapper(@"C:\license.dat");

var result = analyzer.Analyze(
    @"C:\input.png",
    new AnalysisOptions
    {
        Threshold = 80,
        ModelPath = @"C:\model.bin"
    });

if (!result.Ok)
{
    Console.WriteLine(result.Message);
}

C# から見えるのは、string と List<int> と IDisposable です。 IntPtr や解放関数やネイティブ文字列バッファの都合は見えません。 ここが大きいです。

7. それでも C++/CLI を選ばないほうがよいケース

もちろん、C++/CLI は万能ではありません。 選ばないほうがよい場面もあります。

• 相手が最初からきれいな C API を公開している
  • この場合は P/Invoke のほうが素直です。
• クロスプラットフォームが必要
  • C++/CLI は Windows 前提です。
• 境界面が小さく、型も単純
  • ラッパー DLL を増やすコストのほうが大きいことがあります。
• AOT や配布制約をかなり厳密に見ている
  • 構成全体の要件を先に見たほうがよいです。

最後の「AOT や配布制約」だけ抽象的なので、実際に効いてくる制約を並べておきます。ここは .NET Framework 時代の感覚のままだと踏みやすいところです。

なお、C++/CLI プロジェクトが .NET（.NET Core 系）をターゲットにできるのは Visual Studio 2019 以降です。それより古い環境しかないなら、まず .NET Framework 前提で考えることになります。

つまり、判断基準は「ネイティブ DLL の複雑さに対して、どこで翻訳するのがいちばん自然か」です。 単純なら P/Invoke、複雑なら C++/CLI。 この切り分けでだいたいうまくいきます。

flowchart TB
    accTitle: C++/CLIを選ばないほうがよい場面
    accDescr: きれいなC APIが既にある、クロスプラットフォームが必要、境界面が小さく型も単純、AOTや配布制約を厳密に見ているという4つの場面では、C++/CLIラッパーを選ばないほうがよいことを示す。
    n1["C APIが既にある"] --> no["C++/CLIを選ばない"]
    n2["クロス対応が必要"] --> no
    n3["境界が小さく型も単純"] --> no
    n4["AOT・配布制約が厳格"] --> no
    no -.-> judge["どこで翻訳するのが自然か"]

図14: C++/CLIは万能ではない。この4つに当てはまるなら、P/Invokeや構成の見直しが先。

8. まとめ

C# からネイティブ DLL を使う方法として、P/Invoke は今でも王道です。 ただし、それは 相手が C API として素直なとき の話です。

ネイティブ側が C++ ライブラリとして設計されているなら、 C# 側に IntPtr とマーシャリング属性を並べて頑張るより、C++/CLI で薄いラッパーを作ったほうが境界面がきれいに保てる ことが多いです。

特に、

• クラスベースの API
• 所有権の前提
• std::wstring や std::vector
• 例外変換
• コールバック
• 段階的な移行

が絡むなら、C++/CLI はかなり現実的な選択肢です。

やることは派手ではありません。 でも、こういう「境界をどこで整えるか」は、後の保守性にきっちり効いてきます。 Windows の既存資産と .NET を一緒に生かしたいとき、C++/CLI はまだまだ便利です。

9. 参考資料

• この記事のサンプルコード一式（ネイティブ C++ ライブラリ、C++/CLI ラッパー、C# 消費側） - komurasoft-blog-samples (GitHub)
• Mixed (Native and Managed) Assemblies - Microsoft Learn
• .NET programming with C++/CLI - Microsoft Learn
• Migrate C++/CLI projects to .NET - Microsoft Learn
• How to: Define and consume classes and structs (C++/CLI) - Microsoft Learn
• /clr (Common Language Runtime compilation) - Microsoft Learn
• Native AOT deployment overview - Microsoft Learn
• Using C++ Interop (Implicit PInvoke) - Microsoft Learn
• Platform Invoke (P/Invoke) - Microsoft Learn
• Overview of Marshaling in C++/CLI - Microsoft Learn
• marshal_as - Microsoft Learn
• Interop (C++) のパフォーマンスに関する考慮事項 - Microsoft Learn

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

P/InvokeとC++/CLIラッパーはどう使い分ければよいですか？

相手が extern "C" で公開されたフラットな C の関数群なら、P/Invoke が素直で一番簡単です。相手が C++ のクラス中心のライブラリで、所有権・文字列・配列・例外・コールバックが絡むなら、C++/CLI で薄いラッパーを1枚挟むほうが保守しやすくなります。判断基準は「ネイティブ DLL の複雑さに対して、どこで翻訳するのがいちばん自然か」で、単純なら P/Invoke、複雑なら C++/CLI という切り分けでだいたいうまくいきます。

C++/CLIラッパーを挟むと何が楽になりますか？

C++/CLI 側ではネイティブのヘッダーをインクルードして std::wstring や std::vector を C++ の型のまま扱えるため、C# 側で C++ の世界を再現する必要がなくなります。C# には string、byte[]、List<T>、IDisposable、例外といった .NET らしい API だけを見せられ、IntPtr や解放関数、マーシャリングの都合は隠せます。C++ 例外やエラーコードを境界で .NET の例外に変換でき、既存資産を活かした段階的移行もしやすくなります。

P/Invokeだけで進めるとつらくなるのはどんなときですか？

ネイティブ DLL が C++ のクラス中心で設計されている場合、P/Invoke で直接呼べるのは DLL のエクスポート関数だけなので、結局どこかで C 形式の関数に落とす層が必要になり、実質的に C 互換 API の設計を始めることになります。さらに std::wstring や std::vector を返したい、コールバックで進捗を受けたい、C++ 例外が飛ぶ、といった要素が増えると、C# 側に MarshalAs や手動バッファ、デリゲートの寿命管理が積み上がっていきます。所有権や寿命の前提を IntPtr ベースで表現すると、後から読み返したときにかなりつらくなります。

C++/CLIを選ばないほうがよいケースはありますか？

あります。相手が最初からきれいな C API を公開しているなら P/Invoke のほうが素直です。また C++/CLI は Windows 前提なので、クロスプラットフォームが必要な場合は使えません。境界面が小さく型も単純な場合はラッパー DLL を増やすコストのほうが大きいことがあり、AOT や配布制約を厳密に見ている場合も構成全体の要件を先に確認したほうがよいです。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。