2010-11-28 4 views
0

Разве это пустая трата времени или есть очевидный & измеримый выигрыш в создании .NET-оболочки неуправляемой библиотеки DLL?Каковы преимущества и недостатки создания .NET-оболочки неуправляемой библиотеки DLL?

Дополнительная информация:

  • Я не контролируем DLL, однако я могу решить, чтобы не заменить его новой версии.
  • В DLL есть много классов. И многие поддерживающие перечисления.
  • DLL предоставляет проект с критическими функциями.

ответ

1

Несколько преимуществ, которые я знаю:

  1. Вы можете поместить xmldoc в управляемой оболочки и, следовательно, имеют документацию, доступную для всех разработчиков внутри IDE.
  2. Вы можете абстрагировать все IntPtr s, что может стать источником проблем и ошибок для менее опытных разработчиков.
  3. Вы можете создавать операции более высокого уровня для общих сценариев из блоков нижнего уровня в неуправляемой DLL, что уменьшает вероятность ошибок. (Конечно, это не относится к обертке неуправляемых DLL).
1

Вы можете обернуть управление ресурсами, используемыми в коде 3 партии с кодом, который реализует IDisposable, который позволит обеспечить сбор мусора .NET, которые будут использоваться, чтобы высвободить ресурсы (дескрипторы файлов и т.д.), которые вы больше не с помощью.

Другие преимуществ - стандартное для почти всех 3-кода партии включают в себя:

Вы изолирующие большую часть вашего кода от каких-либо изменений, которые могут произойти в партии DLL 3 в будущем. Если что-то изменится, вам просто нужно изменить реализацию в вашем классе-оболочке. Остальная часть вашего кода остается неизменной.

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

+0

ОК ChrisF, но я могу выбрать не обновлять DLL. Поэтому у меня нет этой проблемы. – 2010-11-28 16:24:54

+0

@Pierre - обновленный ответ. – ChrisF 2010-11-28 16:27:46

+0

Спасибо за ваш вклад Крис! – 2010-11-28 16:29:25

2

Плюсы:

  1. Это намного проще в использовании, функциональность DLL в .NET проектов
  2. Вы можете написать свой собственный загрузчик неуправляемых DLL, так что вы не должны полагаться на алгоритм в LoadLibrary.
  3. Вы можете добавить изоляцию позже, так что неуправляемые DLL остается из собственного процесса

Минусы:

  1. Это много работы

Если вы можете обернуть DLL а затем также обеспечить более простой, меньший интерфейс с тем, что вам нужно, тогда это может стоить того.

Кроме того, я знаю, что вы сказали, что не можете управлять DLL, но если бы вы могли, C++/CLI-обертка .lib намного удобнее использовать неуправляемый код.NET (в основном, это касается других, которые видят этот вопрос, или если вы можете получить доступ).

0

Если вы хотите использовать эту DLL в проекте C# или VB.NET (или любом другом языке .net, кроме C++/CLI), я не вижу разумной альтернативы (при условии, что вы не собираетесь воссоздавать управляемый версию DLL полностью с нуля). Конечно, вы могли бы использовать COM вместо этого, но в большинстве случаев это будет сложнее и намного больше работать с гораздо худшим результатом с точки зрения проекта .NET.

EDIT: ОК, в соответствии с вашими комментариями DLL уже a COM Dll. Тогда вам, конечно, не нужна оболочка .NET. Мой ответ был рассчитан на случай, если у вас есть простая DLL на C++, где использование COM означает «добавление COM-оболочки» к нему.

3

DLL, имеет много классов

Это странный вопрос, но важные детали отсутствуют. Если вы хотите использовать эти классы из управляемого кода, то у вас есть нет выбора, но написать обертку C++/CLI для них. Только компилятор C++ может правильно их построить. P/Вызов конструктора технически невозможен, хотя довольно сложно найти его экспортированное имя функции, вы не можете догадаться, сколько памяти выделяется для объекта. Только компилятор C++ знает.

Нанесение оберток не очень сложно, оно в значительной степени механическое. Более подробную информацию об этом вы найдете в ссылках в this answer.

1

Плюсы:

1) Какая-то безопасность ваших алгоритмов, если они находятся в DLL неуправляемый;

2) Предотвращение узких мест GC. Полный контроль над памятью;

Минусы:

1) Вы должны поддерживать оба 32-х и 64-битную сборку вашего неуправляемых DLL, если вы хотите использовать 64-разрядные .Net среду;

2) Необходимо создать очень крошечный интерфейс (мост) между управляемым и неуправляемым кодом для предотвращения ухудшения скорости. Иногда это невозможно;

Смежные вопросы