Объединение C++ и C#

Действительно ли это - хорошая идея объединить C++ и C#, или это излагает какие-либо непосредственные проблемы?

У меня есть приложение, для которого нужны некоторые части, чтобы быть C++ и некоторыми частями, чтобы быть C# (для увеличенной эффективности). Каков был бы лучший способ достигнуть использования собственного C++ dll в C#?

29
задан cam 28 March 2010 в 12:42
поделиться

2 ответа

Да, использование C # и C ++ для вашего продукта является очень распространенная и хорошая идея.

Иногда вы можете использовать управляемый C ++, и в этом случае вы можете использовать свой управляемый модуль C ++ так же, как любой другой модуль .NET.

Обычно вы делаете все, что можете, на C #. Для частей, которые вам нужно сделать на C ++, вы обычно создаете C ++ DLL, а затем вызываете эту DLL из C #. Маршалинг параметров выполняется автоматически за вас.

Вот пример импорта функции C внутри DLL в C #:

[DllImport("user32", CharSet=CharSet.Auto, SetLastError=true)]
internal static extern int GetWindowText(IntPtr hWnd, [Out, MarshalAs(UnmanagedType.LPTStr)] StringBuilder lpString, int nMaxCount);
34
ответ дан 28 November 2019 в 01:15
поделиться

Вопрос явно в том, как интегрировать его собственный C++ код в его C# решение, а не просто какой атрибут использовать для вызова существующей функции из win32 API. Даже если ответ уже был принят, я считаю его неполным, и следует применить следующее.

Да, это обычная практика в случаях, когда задача может либо выполняться быстрее, либо использовать меньше ресурсов, а также в некоторых случаях для доступа к методам, недоступным в .net framework.

Если ваша цель - повысить эффективность, вам нужно написать родную неуправляемую библиотеку C++, вы создадите новый неуправляемый проект C++ (который компилируется как библиотека dll) в visual studio и будете ссылаться на эту библиотеку из вашего проекта C#.

В вашем случае, похоже, вы пишете неуправляемую библиотеку C++, и здесь применимо следующее.

Что касается непосредственных проблем, о которых вы спрашивали, то это повлияет на развертывание и обфускацию.

  • Развертывание: Имейте в виду, что библиотеки C# DLL, которые вы создадите, будут работать на любом процессоре, как 32, так и 64-разрядном, но эта новая родная и неуправляемая библиотека C++ будет заставит вашу программу быть либо для 32 или 64.

    Это то, что вы настроите в вашем менеджере конфигурации Visual Studio, и об этом позаботятся во время компиляции во время компиляции, вы выберете AnyCPU для C# сборки и для вашей новой неуправляемой библиотеки C++, которая будет находиться в отдельном проекте, вам нужно будет выбрать win32 или x64.

    Итак, у вас теперь будет 2 установки, и это рекомендуется иметь отдельные установки, одна для 32 и другая для 64. Или, поскольку 32-битная поддержка сокращается очень быстро, вы можно сосредоточиться только на 64-битных.

    Также, ваша библиотека может ссылаться на VC++ redistibutable, предоставляемый Visual Studio, который вам, возможно, придется включить в развертывание, хотя некоторые версии этого пакета включены во многие ОС, я обнаружил, что это редко тот же самый пакет, с которым я компилировал, и лучше развернуть его с вашим приложением, чтобы быть уверенным. Если этот пакет отсутствует, на целевой машине в журнале eventviewer->application появится исключение SideBySide.

    Чтобы поймать и обработать исключение, выброшенное из неуправляемого кода, единственное исключение, которое работает - это пустое исключение, то есть то, в котором нет типа исключения в скобках после catch(). Таким образом, вы можете обернуть свои вызовы неуправляемого кода в этот catch, чтобы обработать все неуправляемые исключения, брошенные из неуправляемого кода, если вы поместите .net тип, например catch(Exception), он просто перепрыгнет через него. Единственный способ поймать неуправляемое исключение внутри управляемого кода - в таком формате.


    try
    {
       //call unmanaged code
    }
    catch
    {
       //handle unmanaged exception
    }

  • Обфускация: Любые вызовы методов, выполненные из C#, которые теперь вызывают неуправляемый код, теперь будут исключены из переименования автоматически. И с другой стороны, если вашей неуправляемой библиотеке C++ нужно вызывать методы из ваших управляемых сборки, их нужно будет исключить из переименования вручную, чтобы они были видимыми для вызывающей их библиотеки C++. их.

Если вам нужно только вызывать хорошо известные библиотеки C++, такие как библиотеки Windows, вам НЕ нужно создавать новый неуправляемый проект C++, а только использовать атрибут [DllImport()], предложенный в предыдущем ответе. И в этом случае вы можете взглянуть на эту ссылку http://www.pinvoke.net/

36
ответ дан 28 November 2019 в 01:15
поделиться
Другие вопросы по тегам:

Похожие вопросы: