Home › forums › Forums for Groups › 4GL/ABL General Programming

.NET -> Porgress ( Think not of a .NET Bridge but of a .Progess Bridge)

Fri, 2010-10-08 14:56 — scrape

Curious Question: Can I access/call or use Progress objects from .Net(c#) code? (P/Invoke?)

Example: I'm programming an application in .Net and I have my business logic coded in ABL objects, I would like to instantiate and use the ABL objects directly from c#.
Think of it as an "reverse .NET Bridge" or a "Progress Bridge"

I currently work at a company that uses both .Net and Progress extensively.
We have business logic code in Progress as well in .Net. (this will not change).
In some situations it would make our life very easy if we could mix and match ABL and .NET code.

The .NET Bridge is already a very big step in achieving this. Example we now use the .NET Class System.Text.RegularExpressions.Regex for optimized validation in Progress.

Note: I am not looking for a solution that uses web-services or the AppServer.
Tips1: .NET has P/Invoke (platform invocation) and Java has JNI (Java Native Interfaces) site:
Tip2: It would be nice if I could wrap the OOABL objects in .NET objects via P/Invoke

Thanks in advance for your suggestions!


‹ OE Architect in Linux Calling Progress Form from existing 4GL MDI ›

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Fri, 2010-10-08 16:36 — tamhas
tamhas's picture

Well, the solution exists,

Well, the solution exists, but you don't seem to want to use it. The OpenClient technology in AppServer provides a very natural and effective way to do this. Sonic or FUSE would be another possibility. The idea of somehow wrapping a .r file for use by .NET code doesn't make much sense, frankly, since the ABL code requires the AVM to be executable. So, somewhere you need an AVM.


Mon, 2010-10-11 11:03 — scrape
scrape's picture

Thanks for your suggestions

Lots of thanks,

I shall look into the solutions you suggest! (AppServer,Sonic,FUSE)

Concerning "The idea of somehow wrapping a .r file for use by .NET code".

I would like to elaborate on this:
I am very aware of the fact that ABL code requires the AVM to be executable.
Just as .NET code requires the CLR (Common Language Runtime) to be executable.

I would like to use OOABL objects from my C# (.NET) code.
This would mean that the .NET CLR would need to communicate with the AVM.
Which is currently not possible to my understanding.

    But I could imagine it would work a little something like this: ".NET Code -> [CLR <-> AVM ]-> OOABL code"

      1) This would mean that .NET code would indicate that it would like to use a OOABL object.
      2) The .NET CLR would request the OOABL object from the AVM. (hence the term "Progress Bridge")
      3) The AVM would then marshall an instance of the OOABL object back to the .NET CLR.

To my knowledge the current .NET bridge in Progress works in much of the same way only the other way around.
And that's why it is possible to use .NET library's from OOABL code.

NOTE: I recently (4 months) switched to Progress after programming 5 years in .NET.
And there for my questions may seem some what naïve due to the lack of a vast Progress knowledge.


Mon, 2010-10-11 16:47 — tamhas
tamhas's picture

You could, of course, do

You could, of course, do this by doing it backwards, i.e., having the AVM be the driver and use the bridge. Recognize, though, that even that is limited in some significant ways because the .NET is inherently multithreaded and the ABL side is singlethreaded. Any event on the .NET side which you want the ABL to notice has to happen on the main thread.

One further option would be to have the .NET session launch an AVM with a start up program that would open a socket connection with the .NET side. Then, you could communicate with the ABL session via the socket. This would cost you the start up of a AVM session at the beginning, but could be reasonably performant after that.


Wed, 2010-10-13 10:43 — scrape
scrape's picture

Intresting : having the .NET session launch an AVM !

Thanks for your reply.

The option "having the .NET session launch an AVM with a start up program" that you suggested is very interesting.
A small penalty at start-up seems very reasonably.

Practicing caution with the use of this option is a wise idea.
It is by far not a silver bullet, but comes in very handy in certain situations.


Fri, 2010-10-08 15:08 — hltool

OE 10.2B I'm also interested

OE 10.2B

I'm also interested in this. We don't have Appserver and would also like to re-used OOABL objects from .NET.
I have concerns about how you would connect to your DB's however, would they be Openedge or SQL? All my OOABL assumes we are already connected, would you have to add (if not connected (db1) then connect (db1)) routines to your OOABL then?