C# מול native DLL: מתי P/Invoke ומתי C++/CLI wrapper

הצורך לקרוא מ-C# ל-DLL קיים של Windows, או לקוד native שכבר רץ בשטח, די נפוץ. אם בצד השני יש C interface פשוט כמו Win32 API, P/Invoke מספיק.

בשטח מקבלים לרוב DLL עם אופי אחר. יש C++ classes, יש כללי ownership, יש exceptions, ו-std::wstring / std::vector מופיעים כדבר שבשגרה. אם דוחפים את זה רק עם P/Invoke, הגבול בין השפות נהיה קשה יותר עם הזמן.

המאמר מסביר מה נהיה קל יותר כששמים C++/CLI wrapper דק אחד במצבים כאלה. זה לא טענה ש-P/Invoke רע. הנקודה היא שהמקרים שבהם P/Invoke מספיק שונים מהמקרים שבהם C++/CLI משתלם.

קטעי הקוד כאן מפורסמים ב-GitHub כסט דוגמאות שאפשר לבנות: native C++ library, C API bridge, C++/CLI wrapper, וקוד C# שצורך גם את גרסת P/Invoke וגם את גרסת C++/CLI.

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

למי זה מיועד, ומה מניחים

המאמר מיועד למפתחים שכבר קראו מ-C# ל-native DLL ויודעים לכתוב DllImport, אבל נתקעים ברגע שהצד השני הוא C++ class library. ניסיון קודם ב-C++/CLI לא נדרש. אם עוד לא כתבתם P/Invoke בכלל, מהיר יותר להתחיל מ-קריאה בטוחה ל-Win32 API מ-C# — מדריך מעשי ל-P/Invoke.

הסביבה המונחת היא Windows + Visual Studio 2022, עם C++/CLI wrapper (.vcxproj) ופרויקט C# באותו solution. היעד יכול להיות .NET Framework או למשל .NET 8. בצד .NET יש מגבלות ייחודיות, והן בפרק 7.

מונחים שכדאי להכיר

תוכן עניינים

1. המסקנה בקצרה
2. מתי P/Invoke מספיק
3. איפה P/Invoke נהיה קשה בבת אחת
4. מבנה עם C++/CLI wrapper
5. מה נהיה קל יותר עם C++/CLI
6. קטעי קוד
7. מתי עדיף לא לבחור ב-C++/CLI
8. סיכום
9. מקורות

ב-diagram, solid line מציינת relation שתמיד מתקיים ו-dashed line מציינת relation מותנה (התנאים מופיעים בהסבר של כל relation ב-detail page). הרשימה המלאה של ה-relations (סה”כ 21, כולל evidence ו-certainty) וההגדרות של ה-concepts המרכזיים נמצאות ב-detail page של ה-knowledge map (ביפנית). Data: JSON-LD / Turtle

1. המסקנה בקצרה

• אם בצד השני יש C functions, P/Invoke הוא הדרך הטבעית
• אם זו C++ library, C++/CLI wrapper אחד מקל על התחזוקה
• במיוחד כשיש classes, ownership, strings, arrays, exceptions ו-callback, עדיף לא להעמיס את זה על צד C#

במילים אחרות: לא מכניסים את אילוצי ה-native DLL ישר ל-C#. את האילוצים ה-native מקבלים בצד C++, ול-.NET מראים רק את הפנים שמתאימה לו. כשהחלוקה הזו עובדת, גם הקוד וגם ה-debug נהיים הרבה יותר רגועים.

flowchart TB
    accTitle: החלוקה לפי צורת ה-DLL בצד השני
    accDescr: אם בצד השני יש C functions, P/Invoke הוא הדרך הטבעית. אם זו C++ library, מוסיפים C++/CLI wrapper אחד. זו מסקנת המאמר, כהסתעפות.
    q{"מה צורת ה-DLL בצד השני"}
    q -->|"C functions"| pi["P/Invoke הוא הטבעי"]
    q -->|"C++ library"| cli["מוסיפים C++/CLI wrapper"]
    cli -.-> note["את האילוצים ה-native מקבלים בצד C++"]

איור 1: החלוקה בקצרה. C functions —‏ P/Invoke. C++ library —‏ C++/CLI wrapper.

2. מתי P/Invoke מספיק

אם P/Invoke סוגר את הבעיה, זה הפתרון הפשוט ביותר. אין סיבה לדחוף C++/CLI בכוח.

P/Invoke מתאים, למשל, למקרים האלה.

• ה-API הוא פונקציות שטוחות שיוצאות ב-extern "C"
• ה-arguments וערכי ההחזרה מסתפקים ב-integers, pointers, structs פשוטים
• כללי ה-string ברורים, ואחריות ה-buffer פשוטה
• ניהול המשאבים ברור, כמו Create / Destroy
• אפשר לכתוב SafeHandle ו-StructLayout בפשטות בצד C#

אם המצב מסודר כך, מספיק להצהיר ב-C# ולהשתמש. זה קרוב לתחושה של קריאה ל-Windows API, והמימוש נשאר קריא.

flowchart TB
    accTitle: התנאים שמאפשרים לקבוע ש-P/Invoke מספיק
    accDescr: כשיש C API שטוח, arguments וערכי החזרה פשוטים, וכללי string ומשאבים ברורים, מספיק להצהיר ב-C# ולהשתמש.
    c1["C API שטוח (extern C)"] --> ok["P/Invoke מספיק"]
    c2["arguments וערכי החזרה פשוטים"] --> ok
    c3["כללי string ומשאבים ברורים"] --> ok
    ok --> use["מספיק להצהיר ב-C# ולהשתמש"]

איור 2: אם ה-API בצד השני מסודר כך, אין צורך לדחוף C++/CLI בכוח.

3. איפה P/Invoke נהיה קשה בבת אחת

הבעיה מתחילה כשזה כבר לא “סתם C API”. משם האווירה משתנה מהר.

3.1. כשמתחילים לעבוד מול C++ classes

אם ה-native DLL מתוכנן סביב C++ classes, בפועל רוצים לקרוא ל-methods של ה-class. מה ש-P/Invoke יכול לפגוש ישירות הן רק export functions של ה-DLL. כלומר, בסוף צריך שכבה שמורידה לפונקציות בסגנון C במקום כלשהו.

בשלב הזה, מה שעושים זה כמעט “לכתוב wrapper”. אם ככה, עדיף להעביר את ה-wrapper לצד C++, במקום לגדל ב-C# הרבה IntPtr ופונקציות release.

flowchart TB
    accTitle: התוצאה של בחירה ב-P/Invoke מול C++ classes
    accDescr: רוצים לקרוא ל-methods של C++ class, אבל P/Invoke יכול לפגוש רק export functions, ולכן צריך שכבה שמורידה לסגנון C. בפועל כותבים wrapper.
    want["רוצים לקרוא ל-methods של C++ class"] --> limit["אפשר לקרוא רק ל-export functions"]
    limit --> bridge["צריך שכבה שמורידה לסגנון C"]
    bridge --> fact["בפועל כותבים wrapper"]
    fact -.-> better["אז עדיף להעביר אותו לצד C++"]

איור 3: גם אם מנסים להסתדר עם P/Invoke, מול C++ class בסוף כותבים wrapper במקום כלשהו.

3.2. כש-ownership ו-lifetime קשים לראות

ב-C++ שאלות כאלה רגילות לגמרי:

• האם הצד הקורא משחרר
• האם ה-pointer שחוזר הוא “השאלה”
• האם זה const& או העברת ownership
• האם יש cache פנימי עם הנחות על lifetime

אם מייצגים את זה ב-C# על בסיס IntPtr, זה עשוי לעבוד בהתחלה, אבל אחר כך קשה מאוד לקרוא מחדש. ברגע שמתחילה השאלה “מי מוחק את ה-pointer הזה, ומתי”, הגבול מתערפל מהר.

flowchart TB
    accTitle: איך ייצוג ב-IntPtr מערפל הנחות ownership
    accDescr: מי משחרר, האם זו השאלה או העברת ownership, והאם יש הנחות lifetime. כשמייצגים את זה ב-IntPtr ב-C#, אחר כך קשה לקרוא והגבול מתערפל.
    q1["מי משחרר"] --> ptr["מיוצג ב-IntPtr של C#"]
    q2["השאלה או העברת ownership"] --> ptr
    q3["האם יש הנחות lifetime"] --> ptr
    ptr --> bad["עובד בהתחלה, אחר כך קשה לקרוא"]
    bad --> muddy["הגבול מתערפל מהר"]

איור 4: כשמייצגים ownership ו-lifetime ב-IntPtr, מגיעה שאלת “מי מוחק ומתי”, והגבול מתערפל.

3.3. כשנכנסים std::wstring, std::vector, callback ו-exceptions

מכאן P/Invoke נכנס לאזור של “אפשר לכתוב, אבל זה לא נעים”.

• רוצים לייצג std::wstring ישירות מ-C#
• רוצים להחזיר std::vector<T>
• רוצים לקבל progress של עיבוד native דרך callback
• בכישלון נזרקת C++ exception

ככל שהיסודות האלה מצטברים, בצד C# מצטברים גם MarshalAs, buffers ידניים, arrays באורך קבוע, ניהול lifetime של delegate, ופענוח קודי שגיאה.

אפשר לכתוב את זה במאמץ. הקושי הוא שהמאמץ לא במקום הנכון. מה שרוצים באמת זה business logic או UI, לא התגוששות עם הגבול.

flowchart TB
    accTitle: הצטברות העומס בצד C# כשעולים יסודות C++
    accDescr: ככל שרוצים להחזיר wstring או vector, לקבל progress ב-callback, ושנזרקות C++ exceptions, כך מצטברים ב-C# MarshalAs, buffers ידניים, וניהול lifetime של delegate.
    e1["רוצים להחזיר wstring או vector"] --> pile["הקוד בצד C# מצטבר"]
    e2["רוצים לקבל progress ב-callback"] --> pile
    e3["בכישלון נזרקת C++ exception"] --> pile
    pile --> load["MarshalAs, buffers ידניים"]
    pile --> load2["lifetime של delegate, פענוח שגיאות"]

איור 5: ככל שמצטברים יסודות אופייניים ל-C++, כך מצטבר גם העומס על קוד הגבול ב-C#.

3.4. כשלא רוצים להוציא את אילוצי C++ ל-C#

ה-API של ה-native DLL לא בהכרח מתאים ישירות ל-C#.

למשל בצד ה-native:

• מחברים כמה קריאות method לתהליך אחד
• שגיאות חוזרות ב-return value וב-out argument
• יש הנחות על סדר אתחול
• יש מגבלות thread-safety

גם עם תכנון כזה, לרוב רוצים להראות ל-C# API הרבה יותר טבעי. כשכבה שממירה את זה, C++/CLI נוח מאוד.

flowchart TB
    accTitle: שכבה שממירה את האילוצים ה-native ומציגה API ל-C#
    accDescr: אילוצי התכנון של ה-native API, כמו סדר אתחול ומגבלות thread-safety, מתקבלים בשכבת ההמרה של C++/CLI, ול-C# מוצג API טבעי יותר.
    nat["אילוצי התכנון של ה-native API"] -.-> ex["סדר אתחול, מגבלות threads וכו"]
    nat --> conv["שכבת ההמרה של C++/CLI"]
    conv --> api["ל-C# מוצג API טבעי"]

איור 6: לא חושפים ל-C# ישירות את אילוצי התכנון בצד ה-native. שמים C++/CLI כשכבת המרה.

4. מבנה עם C++/CLI wrapper

מבחינת מבנה זה פשוט.

flowchart LR
    accTitle: מבנה שלושת השכבות של האפליקציה
    accDescr: אפליקציית C# קוראת ל-C++/CLI wrapper DLL דרך API שמיועד ל-.NET, וה-wrapper קורא ל-native C++ DLL עם headers וטיפוסים native ישירות.
    Cs["אפליקציית C#"] -->|"API שמיועד ל-.NET"| Wrapper["C++/CLI wrapper DLL"]
    Wrapper -->|"headers וטיפוסים native ישירות"| Native["native C++ DLL"]

איור 7: מבנה עם C++/CLI wrapper DLL אחד בין אפליקציית C# ל-native C++ DLL.

מה שנראה מ-C# הוא רק API בסגנון .NET, ואת אלה סוגרים בצד C++/CLI:

• המרת strings
• המרת arrays ו-vectors
• המרת exceptions
• סידור ownership
• פענוח קודי שגיאה
• אם צריך, ספיגה של גבולות thread ו-callback

מה שחשוב: לא לגדל יותר מדי את פרויקט ה-C++/CLI עצמו. התפקיד הוא רק “תרגום” ו”עיצוב ל-.NET”. אם מכניסים גם business logic, השכבה הזו הופכת בעצמה לשחקן הראשי.

flowchart TB
    accTitle: העבודה שנשארת בתוך C++/CLI wrapper
    accDescr: תפקיד C++/CLI wrapper הוא המרת strings ו-arrays, המרת exceptions וקודי שגיאה, וסידור ownership. רק תרגום ועיצוב, בלי business logic.
    w["תפקיד C++/CLI wrapper"] --> t1["המרת strings ו-arrays"]
    w --> t2["המרת exceptions וקודי שגיאה"]
    w --> t3["סידור ownership"]
    w -.-> warn["לא מכניסים business logic"]

איור 8: תפקיד ה-wrapper מוגבל לתרגום ולעיצוב. חשוב לא לגדל אותו יותר מדי.

5. מה נהיה קל יותר עם C++/CLI

5.1. אפשר לעבוד עם טיפוסי C++ כמו שהם

זה יתרון גדול. בצד C++/CLI אפשר לעשות include ל-headers ה-native, ולהשתמש בטיפוסי C++ כמו שהם.

כלומר, אין צורך “לשחזר את עולם ה-C++” בכוח בצד C#. גם std::wstring וגם std::vector אפשר לקבל קודם כטיפוסי C++, ורק אחר כך להעביר ל-.NET בצורה שנדרשת.

flowchart TB
    accTitle: הזרימה מקבלת טיפוסי C++ עד המעבר ל-.NET
    accDescr: עושים include ל-headers ה-native, מקבלים wstring או vector כטיפוסי C++ בצד C++/CLI, ממירים לצורה שנדרשת, ומעבירים ל-.NET. ב-C# לא צריך לשחזר את עולם ה-C++.
    nt["wstring או vector native"] --> recv["מתקבל כטיפוס C++ בצד C++/CLI"]
    recv --> conv["ממירים לצורה שנדרשת"]
    conv --> net["מועבר לצד .NET"]
    net -.-> nofake["ב-C# לא משחזרים את עולם ה-C++"]

איור 9: מקבלים קודם את טיפוסי C++ כטיפוסי C++, וממירים ל-.NET רק כשצריך.

5.2. אפשר לעצב את ה-API ל-.NET

בצד C# אפשר לחשוף צורה מוכרת:

• string
• byte[]
• List<T>
• IDisposable
• exceptions

ההבדל נראה קטן, אבל הוא משנה משמעותית את העומס על מי שצורכים את ה-API. במיוחד בפיתוח צוותי: גם מי שלא מכיר את הצד ה-native יכול לגעת בקוד בלי להיתקע.

5.3. קל יותר ליישר אחריות על exceptions ושגיאות

כשבצד ה-native מעורבים גם exceptions וגם error codes, קשה לקבל את זה כמו שזה ב-C#. בצד C++/CLI אפשר לרכז פעם אחת:

• להמיר exceptions ל-.NET exceptions
• להמיר error codes ל-exceptions או לטיפוסי תוצאה שיש להם משמעות
• להוסיף את ה-context שצריך ל-log

אם מתרגמים פעם אחת בגבול ל”כישלון שיש לו משמעות”, הצד הקורא נשאר הרבה יותר נקי.

flowchart TB
    accTitle: תרגום exceptions ו-error codes בגבול
    accDescr: exceptions ו-error codes שמתערבבים בצד ה-native מרוכזים פעם אחת בצד C++/CLI. exceptions הופכים ל-.NET exceptions, error codes לצורה שיש לה משמעות, ומתווסף context ל-log.
    mixed["exceptions ו-error codes native"] --> tr["מרוכזים פעם אחת בצד C++/CLI"]
    tr --> e1["exceptions הופכים ל-.NET exceptions"]
    tr --> e2["error codes הופכים לצורה שיש לה משמעות"]
    tr -.-> log["מתווסף context שצריך ל-log"]

איור 10: תרגום חד-פעמי בגבול לכישלון שיש לו משמעות משאיר את צד הקריאה ב-C# נקי יותר.

5.4. אפשר להסתיר מ-C# את השונות ב-ABI

C++ classes ו-methods אינם ABI פשוט כמו C functions. ברגע ש-C# מתחיל לדעת את זה ישירות, אילוצי export functions ו-marshaling צפים החוצה.

עם C++/CLI wrapper אפשר לסגור את אילוצי C++ בצד C++, ולהראות ל-C# רק פנים יציבה. ההפרדה הזו עוזרת גם כשמעדכנים את הספרייה.

flowchart TB
    accTitle: חסימת השונות ב-ABI על ידי ה-wrapper
    accDescr: C++ classes ו-methods אינם ABI פשוט כמו C functions, לכן את האילוצים האלה סוגרים בצד C++, ול-C# מראים רק פנים יציבה. ההפרדה עוזרת גם בעדכון ספרייה.
    abi["ABI של C++ class אינו פשוט"] --> hide["אילוצי C++ נשארים בצד C++"]
    hide --> stable["ל-C# מוצגת רק פנים יציבה"]
    stable -.-> update["ההפרדה עוזרת גם בעדכון ספרייה"]

איור 11: לא חושפים אילוצי marshaling ו-export functions. ל-C# מראים רק פנים יציבה.

5.5. קל לעשות מעבר הדרגתי

לבנות מחדש בבת אחת את כל ה-native DLL הקיים זה עומס כבד. עם C++/CLI wrapper אפשר לעטוף קודם רק את ה-API שצריך, wrapper דק, ולהתחיל להשתמש בו ממסכים חדשים או מ-workflows חדשים ב-C#. זה מקל על מעבר הדרגתי.

זה מתאים היטב כשרוצים להמשיך להשתמש בנכסי Windows קיימים, ובמקביל להעביר את הסביבה בהדרגה ל-.NET.

6. קטעי קוד

כאן אין “דוגמה מלאה שרצה כמו שהיא”, אלא קטעים שמראים את תמונת הגבול.

6.1. דוגמה ל-API בצד ה-native DLL

// 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);
    };
}

כ-native C++ זה API רגיל לגמרי. לגעת בו ישירות מ-C# זה כבר לא פשוט.

6.2. אם מנסים את זה עם P/Invoke, זה נראה כך

קודם כול, כדי לקרוא ישירות מ-C#, צריך במקום כלשהו להוריד לפונקציות בסגנון C. למשל מכינים בנפרד פונקציות bridge כאלה.

// דוגמה ל-bridge שהורד ל-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);
}

אם זה מספיק, מצוין. בפועל מצטברות עוד שאלות:

• איך מחזירים נתונים באורך משתנה
• מי משחרר את ה-string buffer
• איפה שמים את פרטי השגיאה
• איך שומרים על ה-lifetime של ה-callback

כלומר, לעיתים קרובות חשבתם שבחרתם ב-P/Invoke, ובפועל התחלתם לתכנן C-compatible API.

flowchart TB
    accTitle: איך תוכנית P/Invoke הופכת בפועל לתכנון C-compatible API
    accDescr: מתכננים לקרוא ישירות עם P/Invoke, מכינים C bridge functions בנפרד, כותבים SafeHandle ו-StructLayout ב-C#, ומצטברות שאלות של נתונים משתנים, release ו-callback. בפועל מתחיל תכנון C-compatible API.
    start["מתכננים לקרוא ישירות עם P/Invoke"] --> bridge["מכינים C bridge functions בנפרד"]
    bridge --> decl["כותבים SafeHandle ו-StructLayout"]
    decl --> more["שאלות של נתונים משתנים, release, callback"]
    more --> real["בפועל מתחיל תכנון C-compatible API"]

איור 12: מה שהתחיל כ”רק בחרנו ב-P/Invoke” הופך לעיתים קרובות, בלי לשים לב, לתכנון C-compatible API.

הנקודות האלה, כשעוברים ל-C++/CLI, מוחלפות כך. הן לא נעלמות בקסם. הניסוח המדויק יותר: הן עוברות לצורה שקל לכתוב באופן טבעי בצד C++.

6.3. כך אפשר לכתוב עם C++/CLI wrapper

בצד C++/CLI מקבלים את האילוצים ה-native, ומעצבים את ה-API שנחשף ל-C#.

// 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(). שניהם נראים כמו destructor של C++, אבל התפקיד מתאים ל-Dispose pattern של .NET.

השיטה הנפוצה היא לכתוב את שחרור המשאבים ה-native ב-finalizer, ולקרוא לו מתוך ה-destructor. במימוש הבא ~AnalyzerWrapper() פשוט קורא ל-this->!AnalyzerWrapper(). זו בדיוק הנקודה: גם אם צד C# שוכח לקרוא ל-Dispose(), בסוף ה-GC תופס. אם נקרא ה-destructor, GC::SuppressFinalize מדכא את ה-finalization, כך שאין double-free.

שימו לב ש-Dispose(), Finalize() ו-Dispose(bool) נוצרים על ידי ה-compiler, ולכן לא כותבים אותם בעצמכם בצד C++/CLI. מצד שני, גם מקוד C++/CLI אי אפשר לקרוא ישירות ל-Dispose() — קוראים ל-destructor עם האופרטור delete. ההתאמה הזו מסוכמת בסעיף “Destructors and finalizers” של How to: Define and consume classes and structs (C++/CLI) - Microsoft Learn.

flowchart TB
    accTitle: חלוקת התפקידים בין destructor ל-finalizer
    accDescr: קריאת using או Dispose ב-C# מפעילה את ה-destructor, שקורא ל-finalizer ומשחרר את המשאב ה-native. שכחת Dispose גורמת ל-finalizer לרוץ באיסוף GC, ו-SuppressFinalize מונע double-free.
    us["using או Dispose בצד C#"] --> dtor["destructor (מקביל ל-Dispose)"]
    forget["שכחת Dispose"] -.-> gc["ה-finalizer נקרא באיסוף GC"]
    dtor --> fin["קורא ל-finalizer"]
    fin --> del["עושה delete למשאב ה-native"]
    gc -.-> del
    dtor -.-> sup["SuppressFinalize מונע double-free"]

איור 13: השיטה הנפוצה: כותבים את ה-release ב-finalizer וקוראים לו מה-destructor. גם אם שוכחים 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)
{
    // אם קוראים אחרי שהאובייקט כבר disposed, עוצרים כאן לפני הכניסה ל-native.
    // ה-destructor (= Dispose) שם את _native ל-nullptr, ולכן
    // בלי הבדיקה הזו נכנסים ל-native דרך null pointer,
    // וה-process כולו קורס עם access violation במקום .NET exception.
    // מנקודת המבט של C#, ההתנהגות הצפויה היא "אם נוגעים אחרי Dispose,
    // מתקבל ObjectDisposedException" — וזה נדרש בכל method שמשתמש ב-_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, פונקציות release, או אילוצי ה-string buffer ה-native. זה ההבדל הגדול.

7. מתי עדיף לא לבחור ב-C++/CLI

C++/CLI אינו פתרון-על. יש גם מצבים שעדיף לא לבחור בו.

• בצד השני כבר יש C API נקי
  • במקרה הזה P/Invoke פשוט יותר.
• צריך cross-platform
  • C++/CLI מניח Windows.
• הגבול קטן, והטיפוסים פשוטים
  • לפעמים עלות של wrapper DLL נוסף גדולה יותר.
• בודקים בקפדנות רבה מגבלות AOT והפצה
  • כדאי קודם לראות את דרישות המבנה כולו.

כי “מגבלות AOT והפצה” בסעיף האחרון מופשטות, נפרט את המגבלות שבאמת משפיעות בשטח. זו נקודה שקל להיכשל בה אם נשארים עם התחושה מתקופת .NET Framework.

פרויקט C++/CLI יכול למקד ל-.NET (משפחת .NET Core) רק מ-Visual Studio 2019 ואילך. אם יש רק סביבה ישנה יותר, חושבים קודם בהנחת .NET Framework.

כלומר, הקריטריון הוא “איפה הכי טבעי לעשות את ה-translation, ביחס למורכבות של ה-native DLL”. פשוט — P/Invoke. מורכב — C++/CLI. החלוקה הזו בדרך כלל עובדת.

flowchart TB
    accTitle: מצבים שעדיף לא לבחור ב-C++/CLI
    accDescr: כשכבר יש C API נקי, צריך cross-platform, הגבול קטן והטיפוסים פשוטים, או שבודקים בקפדנות מגבלות AOT והפצה — בארבעת המצבים האלה עדיף לא לבחור ב-C++/CLI wrapper.
    n1["כבר יש C API"] --> no["לא בוחרים ב-C++/CLI"]
    n2["צריך cross-platform"] --> no
    n3["הגבול קטן והטיפוסים פשוטים"] --> no
    n4["מגבלות AOT והפצה קפדניות"] --> no
    no -.-> judge["איפה הכי טבעי לעשות translation"]

איור 14: C++/CLI אינו פתרון-על. אם מתקיים אחד מארבעת המצבים האלה, כדאי קודם לבדוק P/Invoke או לשקול מחדש את המבנה.

8. סיכום

כדרך להשתמש ב-native DLL מ-C#, P/Invoke עדיין הדרך המרכזית. אבל זה נכון כשהצד השני פשוט כ-C API.

אם הצד ה-native מתוכנן כ-C++ library, לרוב C++/CLI wrapper דק שומר על גבול נקי יותר, במקום לערום ב-C# הצהרות IntPtr ו-attributes של marshaling.

במיוחד כשמעורבים:

• API מבוסס classes
• הנחות ownership
• std::wstring או std::vector
• המרת exceptions
• callback
• מעבר הדרגתי

אז C++/CLI היא בחירה מציאותית למדי.

מה שעושים כאן לא מרשים במיוחד. אבל השאלה “איפה מיישרים את הגבול” משפיעה בבירור על התחזוקה אחר כך. כשרוצים להמשיך להשתמש גם בנכסי Windows קיימים וגם ב-.NET, C++/CLI עדיין שימושי מאוד.

9. מקורות

• סט קוד הדוגמה המלא של המאמר (native C++ library, C++/CLI wrapper, צד הצריכה ב-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 wrapper?

אם בצד השני יש C API שטוח שיוצא ב-extern "C", P/Invoke הוא הדרך הפשוטה והטבעית. אם זו ספריית C++ מבוססת classes, עם ownership, strings, arrays, exceptions ו-callback, בדרך כלל קל יותר לתחזק wrapper דק ב-C++/CLI. הקריטריון הוא איפה הכי טבעי לעשות את ה-translation ביחס למורכבות של ה-native DLL: פשוט — P/Invoke, מורכב — C++/CLI. החלוקה הזו בדרך כלל עובדת.

מה נהיה קל יותר אחרי שמוסיפים C++/CLI wrapper?

בצד C++/CLI אפשר לעשות include ל-headers ה-native ולעבוד עם std::wstring ו-std::vector כטיפוסי C++ רגילים, בלי לשחזר את עולם ה-C++ ב-C#. ל-C# חושפים רק API בסגנון .NET: string, byte[], List<T>, IDisposable ו-exceptions. IntPtr, פונקציות release ופרטי marshaling נשארים מאחורי הגבול. אפשר להמיר C++ exceptions וקודי שגיאה ל-.NET exceptions בגבול, וגם מעבר הדרגתי על בסיס קוד קיים נהיה קל יותר.

מתי P/Invoke לבד נהיה כואב?

כשה-native DLL בנוי סביב C++ classes, P/Invoke יכול לקרוא רק ל-export functions של ה-DLL. בסוף צריך שכבה שמורידה הכל לפונקציות בסגנון C, ואז בפועל מתחילים לתכנן C-compatible API בעצמכם. ברגע שרוצים להחזיר std::wstring או std::vector, לקבל progress דרך callback, או שיש C++ exceptions — בצד C# מצטברים MarshalAs, buffers ידניים וניהול lifetime של delegate. אם מייצגים ownership ו-lifetime עם IntPtr חשוף, אחר כך קשה מאוד לקרוא את הקוד מחדש.

יש מצבים שעדיף לא לבחור ב-C++/CLI?

כן. אם כבר יש C API נקי, P/Invoke פשוט יותר. C++/CLI מניח Windows, אז cross-platform לא רלוונטי. כשהגבול קטן והטיפוסים פשוטים, עלות של wrapper DLL נוסף לפעמים גדולה מהתועלת. גם אם בודקים בקפדנות מגבלות AOT והפצה, כדאי קודם לראות את דרישות המבנה כולו.

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

מתמחה בפיתוח תוכנה עבור Windows, ייעוץ טכני וחקירת תקלות, בעיקר בפרויקטים עם מערכות קיימות ובאגים שקשה לשחזר.