Subscribe via RSS
Toggle Submenu
  1. Categories
  2. Recent
  3. Tags
View Replies (1)

Resolved COM Automation vs Importing .NET assembly

  1. Advice
0
Votes
Undo
  1. Daryl Foster
    Daryl Foster
  2. PowerBuilder
  3. Friday, 6 October 2023 07:09 AM UTC

Hi All,

I use a few COM Visible .NET Assemblies in our Powerbuilder applications.  I've been using COM Automation via OLEObject with them for years without any issues. Now it's time to update my .NET Assemblies to the latest version of .NET and I wanted to know whether using the .NET assembly importing features is the way to go, or whether I should stick with COM Automation?

Is the .NET assembly importing as reliable as using OLEObject.  What about performance, is using objects created using .NET importing any faster or slower than using OLEObject?  Are there any other considerations I should be aware of?

I currently use PB2019R3, but will probably look at updated to a later version soon.

 

 

Excel export spaces in empty fields (PB2019 Build ...
Automated testing with the Ribbon Menu
Responses (1)
Andreas Mykonios
Andreas Mykonios Accepted Answer Pending Moderation
  1. Friday, 6 October 2023 09:46 AM UTC
  2. PowerBuilder
  3. # 1

Hi.

The main advantage you get by using .NET DLL Importer is that you don't have to use regasm. Also depending on your .net assemblies you may be able to convert them to .net 6 (if you upgrade to PB 2022 R2, PB 2019 can work .net code 3.0 and .net Standard 2.1). Also, in PB 2022 there was an important enhancement in my opinion, support was added to invoke PowerScript events in C# (Enhancements to calling .NET assemblies - - What's New (appeon.com)).

One difference is that when you modify your assembly, you may need to do some modifications to the generated user object (example you add a new method that powerbuilder should be able to call). With com objects you need to do less changes in powerscript... Another difference is that, if I'm not wrong, COM objects do have issues with overloading (example overloaded methods).

Andreas.

Comment
Load more comments
Miguel Leeuwe
  1. Miguel Leeuwe
  2. Friday, 6 October 2023 12:37 PM UTC
with "visible" I mean something like an activex control, not "being" com visible in .net solution.
  1. Helpful
Roland Smith
  1. Roland Smith
  2. Friday, 6 October 2023 12:47 PM UTC
You don't have to use the DLL Importer. You can code an interface object manually if you want. I ended up using COM because we were on 2019 GA at the time. I created a wrapper DLL in C# with simple argument datatypes that are compatible with PB and then made calls to the third party C# DLL to do the actual task.
  1. Helpful
Daryl Foster
  1. Daryl Foster
  2. Friday, 6 October 2023 21:22 PM UTC
Thanks for the replies everyone. For context the 3 main assemblies I’m looking at are all non visual which I wrote and have been using for the past 10 to 15 years. The interface to each is a COM compatible wrapper so I could almost just update the code to the latest version of .NET and leave the interface unchanged so it could almost be a drop in replacement for the existing COM objects.



The interface should be compatible with PB to import, so I was mainly wondering, since the .NET assembly could be used either way is one method more preferable from a reliability and performance perspective? I’ve been a fan of PB COM because it has been rock solid but wondered if maybe it’s old technology.
  1. Helpful
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.