Calling COM Exposed .NET Assembly methods as OLEObject

[Former Member]

I'm prototyping calling a .NET 4.0 assy from PB as a COM object.  Eventual goal is to use .NET assy as WCF client to vendor SOAP services. (Unfortunately neither PB Classic not .NET are able to generate proxies to these services).

I started with a real simple HelloPowerBuilder example in order to understand the pieces and how they fit together.

I followed Bruce's .NET 2.0 example and 4.0 example as well as another older example

The steps are (as I did them)

Create the assembly

Make COM visible

Build it

Test with .NET WinForm

Copy assembly to PB app folder

Add to Registry  (RegAsm)  -- I'm on a 32 bit platform

Here's the registry file -

Write PB test harness code

Life should be good  - 

But it's not?

What am I missing?

How to diagnose a -3 error?

TIA

[former_member190719 · Accepted solution]

If you're on a 64 bit operating system, the REGASM might have created registry entries for a 64 bit app.  You'll need to modify the registry file to relocate the entries to the branch used for 32 bit apps.

The assembly has to go into the GAC until you use the codebase argument to make put it in a specific location on the hard drive.  Or, you could use manifest file rather than the registry and have it as a local assembly.

I'd suggest starting off with the GAC, and then progress to the other options only once you get the GAC approach working.  One step at a time....

[Former Member · Accepted solution]

Add to GAC

RegAsm

Call from PB!

While this is a functional solution. It may not be an ideal solution in an active dual platform development environment where a developer may not want to 'throw the assembly over the fence' to the other platform until perfected. GAC is so,  well... Global

PS

A couple of minor but important details

If using the project to register the assembly for COM use. You need to run visual studio as Administrator

This document details GACUtil command line parameters and proper usage. Having the correct environment for this run is mandatory

[former_member190719 · Accepted solution]

Now that you've got it working, start looking at the Registry Free COM approach.  We use this not only for ActiveX controls, but for the .Net assemblies we call via CCW as well.

While you can create the manifest files needed by hand, I've found Side by Side Manifest Maker to be highly useful in reducing the amount of work involved.

Here's the PBDJ article where I cover the manual approach to creating the manifest files.

[Former Member · Accepted solution]

Pile it thicker and deeper baby!

I am discovering how wonderful and easy it is to write PB Assemblies that wrap WCF service calls compared to the C# 'pure' .NET approach.

Right now specifically, it's the configuration information.  In VS, the easy-to-use Add Service Reference wizard, generates a proxy class that reads its values from a generated and referenced App.XML file

This is great when the proxy is used in the main caller app.  However,

When a Service reference proxy is wrapped in an assembly, The assembly does not automatically read its generated config file. Hence the service instantiation call fails.

Developer must either write code to explicitly read configuration file  (which must be deployed)

OR Supply the values in separate calls from the main app or read values from a db etc

OR Instantiate the binding and address objects supply them (hard code)

With PB, the wizard reads the config file and generates the values into the PB proxy class.  The config file is not used at runtime.  It's a lot simpler to wrap a WCF call in an assembly.

I actually find myself writing the code into a service class ancestor that mimics the code generated by the WCF proxy wizard into the proxy nvo!

Ugh, I will join the chorus of those who enjoy PB productivity and rue the day they were forced to code in pure .NET!

[Former Member · Accepted solution]

To close the discussion here's my resultant prototype solution. It had me instantiating my own Service, Binding and Endpoint classes and laboriously coding their setup based on the setting in the app.config file.  As I go down the road I'll generalize the solution for use with multiple services.

This line does the instantiation.

myHolidayService = new GBSCTHolidayDatesSoapClient(myBinding, myEndpoint);

In a "standard" app.config file set up the call might look like this

myHolidayService = new GBSCTHolidayDatesSoapClient(  );

So this is the basics of how to call a .NET Assembly which wraps a WCF Service Proxy (reference) via a PB OLEObject

Long Live PowerBuilder

[Former Member]

Did you 'Register for COM Interop' from the Build tab?

[Former Member]

this is the same as calling RegAsm from the command line

[Former Member]

Ah, your're right.  My apologies.