.NET DLL из PowerBuilder (10 или 11,5)

Question

Если я собираюсь сослаться на .NET dll из PowerBuilder (10 или 11.5), что из следующего является наилучшей практикой?

1) Зарегистрируйте dll как COM-объект и используйте COM-объект через OleObject. 2) Обновление до 11.5 и преобразование в PB.NET, чтобы в коде PowerBuilder на самом деле были блоки C # 3) Другой метод

Что я должен знать об этих подходах?

Answer 1

Что нужно знать:

Первый подход (COM Wrapper) работает с любой версией PowerBuilder, включая 11.5 и выше, когда вы хотите создать только приложение Win32. Тем не менее, существуют некоторые ограничения в отношении того, что вы действительно можете сделать. Сборка должна быть помечена как видимая COM. Методы, которые вы хотите вызвать, должны быть общедоступными. Если методы перегружены, в будущем могут возникнуть проблемы с версиями. Исключения также являются проблемой, вам нужно реализовать механизм перехвата на стороне .Net, чтобы получить подробную информацию об исключениях.

Второй подход требует не только 11.5 и выше, но также требует, чтобы вы скомпилировали ваше приложение как один из целевых типов .Net (например, WinForm). Учитывая, что вам может потребоваться внести другие изменения, чтобы поддерживать компиляцию как WinForm, вы можете обнаружить, что слишком много работы, чтобы вызвать эту единственную сборку. С другой стороны, если вы движетесь к целям .Net, значит, вы настроены.

Answer 2

Я ничего не сделал с PowerBuilder, но эту технику мы использовали (довольно успешно) в проекте, который не может быть немедленно перенесен с VB6.

1) Мы создали шим / фасад с COM-ссылками для предоставления нужных нам элементов .NET. (Мы также указали атрибуты GUID using, чтобы иметь полный контроль над изменениями совместимости.)

2) Мы ссылались на COM-объекты в нашем коде VB6 (как в коде PowerBuilder), используя встроенную обработку объектов (OleObject в вашем случае).

3) Поскольку элементы были перенесены (в нашем случае на C #), они ссылались на базовые классы .NET вместо COM-прокладки. (Мы пометили прокладку устаревшими тегами, чтобы никто не использовал ее случайно.)

4) После того, как все ссылки на прокладку были перенесены, мы удалили прокладку. (На самом деле мы делали это в два этапа. На первом этапе мы оставляли прокладку включенной, но модифицировали ее, чтобы генерировать исключения и регистрировать всю возможную информацию о вызовах. Таким образом, у нас будет представление о том, где выполняются какие-либо вызовы. сделано из. После подтверждения, что не было никаких проблем, прокладка была удалена на следующем этапе.)

Преимущество этого для нас состояло в том, что миграция может происходить постепенно. Мы решили не раскрывать базовые объекты .NET напрямую, потому что все еще существует некоторый риск их изменения, и нам нужно, чтобы интерфейс COM был как можно более стабильным.

Обновление до PB.NET, безусловно, возможно ... но я не знаю, насколько сложной будет эта миграция. Вы можете найти необходимое время, чтобы сделать миграцию крупным проектом (это, безусловно, было бы для нас).

Другие методы, которые мы рассматривали, но отклонили как неприемлемые для наших нужд:

• Завершение компонентов .NET в другое приложение («служба») и обмен данными с этими компонентами через сокетную связь.

• «Оболочка» для утилит, использующих .NET Framework, и передача информации через (например) файловый механизм.

Что следует знать:

• Модель с резьбой используется с обеих сторон звена. (Сначала мы отсиживались, потому что одна часть системы запускала MTA вместо STA - см. этот вопрос для получения дополнительной информации.)

• Какое исключение на стороне .NET будет выглядеть из вашего приложения. Это может быть очень бесполезной «общей» ошибкой, и даже может показаться, что она в вызывающей программе вместо .NET-кода. Мы добавили запись в журнале на стороне .NET, которая давала более подробные записи о любых исключениях, прежде чем перебрасывать их и позволять вызывающей стороне обрабатывать вещи как можно лучше.

Надеюсь, это поможет. Удачи!

Answer 3

Я на самом деле сталкиваюсь с той же проблемой в данный момент. Мы используем PB 11.5, но мы никак не сможем переместить наше приложение к цели .NET, и выполнение вещей .NET (PowerScript # ...) невозможно в собственных приложениях PB. Итак, я попросил у нашей местной поддержки совета, и они ответили, что Sybase рекомендует использовать PBNI:

1. Создание проекта PBNI с использованием C ++ / CLI (а не стандартного C ++)
2. Используйте часть C ++ для создания классов, которые вы можете использовать в PB
3. Используйте часть CLI для доступа к сборке .NET

Есть хороший пример проекта Роя Кислера на CodeExchange , который называется PB2DOTNET. Поможет пропустить первые несколько шагов (обратите внимание, что код не новый, и вам придется перенести как нативный PB, так и PBNI).

Недостатком этого подхода является то, что он добавляет промежуточный уровень, который вы должны поддерживать. Однако классы PBNI должны быть просто тонкой оболочкой для классов .NET, чтобы можно было легко избавиться от части PBNI, как только вы обновитесь до PB12.