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. 参考資料

この記事の知識マップ

この記事は、C#からネイティブDLLを呼ぶ際、相手がextern Cのフラットな関数群ならP/Invokeが素直だが、C++のクラス中心のライブラリで所有権・文字列・例外・コールバックが絡む場合はC++/CLIで薄いラッパーを挟むほうが保守しやすいと整理します。P/InvokeはSafeHandleやStructLayoutでネイティブ型を表現しつつ結局C形式のブリッジ層を自作することになりがちですが、C++/CLIはmarshal_asによる型変換やデストラクター・ファイナライザーによるDispose/Finalizeパターン、例外の.NET変換をC++側に閉じ込め、C#には安定したAPIだけを見せられます。一方でC++/CLIはWindows専用かつNative AOTと両立せず、/clrコンパイルとijwhost.dllへの依存を伴うため、クロスプラットフォームや配布制約が厳しい場合は選べません。

flowchart LR
    accTitle: C++/CLIラッパーとP/Invokeの使い分けの知識マップ
    accDescr: ネイティブDLLの複雑さに応じてP/InvokeとC++/CLIラッパーをどう選び、マーシャリングや所有権・例外・コールバックの扱い、配布制約がそれぞれどう変わるかを示す図です。
    cpp_cli["C++/CLI"]
    p_invoke["P/Invoke"]
    c_api_bridge["C APIブリッジ層"]
    c_native_api["フラットなC API"]
    cpp_class_native_library["C++のクラス中心のネイティブライブラリ"]
    com_marshaling["マーシャリング"]
    marshal_as["marshal_as"]
    safehandle["SafeHandle"]
    structlayout["StructLayout"]
    dispose_finalize_pattern["Dispose/Finalizeパターン(C++/CLI)"]
    ownership_lifetime_management["所有権・寿命管理"]
    exception_translation["例外の.NET変換"]
    callback_delegate_lifetime["コールバックのデリゲート寿命管理"]
    native_aot["Native AOT"]
    ijwhost["ijwhost.dll"]
    clr_compilation_flag["/clrコンパイルオプション"]
    mixed_assembly["混合アセンブリ"]
    cross_platform_requirement["クロスプラットフォーム要件"]
    p_invoke -.->|"前提とする"| c_api_bridge
    p_invoke -->|"推奨される対応"| c_native_api
    cpp_cli -->|"推奨される対応"| cpp_class_native_library
    p_invoke -->|"用いるのは非推奨"| cpp_class_native_library
    cpp_cli -->|"用いるのは非推奨"| c_native_api
    cpp_cli -->|"利用する"| com_marshaling
    marshal_as -->|"実装を担う"| com_marshaling
    p_invoke -.->|"利用する"| safehandle
    p_invoke -.->|"利用する"| structlayout
    cpp_cli -->|"実装を担う"| dispose_finalize_pattern
    cpp_cli -->|"前提とする"| ownership_lifetime_management
    cpp_cli -->|"実装を担う"| exception_translation
    cpp_cli -.->|"前提とする"| callback_delegate_lifetime
    p_invoke -.->|"前提とする"| callback_delegate_lifetime
    cpp_cli -->|"両立しない"| native_aot
    cpp_cli -.->|"前提とする"| ijwhost
    cpp_cli -->|"で構成できる"| clr_compilation_flag
    cpp_cli -->|"実装を担う"| mixed_assembly
    c_api_bridge -->|"前提とする"| c_native_api
    cpp_cli -.->|"の後継"| c_api_bridge
    cpp_cli -->|"両立しない"| cross_platform_requirement

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

C++ では、

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

C# 側には、

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

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

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

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

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

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

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

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

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

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

C++/CLI ラッパーを挟めば、C++ の都合は C++ 側に閉じ込めて、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 の設計を始めている ことが多いです。

これらの論点は、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」にまとまっています。

// 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。 この切り分けでだいたいうまくいきます。

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