1. yakov werde
  2. PowerBuilder
  3. Friday, 29 November 2019 19:41 PM UTC

Our flagship PB Classic desktop application relies more and more on COM InterOp bridged .NET functionality.  Our bi-monthly release cycle includes changes to both PB and associated .NET code  We formerly deployed .NET code into the GAC.  But when keeping multiple releases in sync proved impossible (PB can't distinguish between strong named folders) we switched to .exe.manifest driven side-by-side deployment.  This mechanism works flawlessly and seamlessly.  Multiple releases can co-exist in a CLIENT RUNTIME workstation environment.

We are even able to keep our IDE based PB Dev time Runs GAC-less by installing assemblies and their dependencies side-by-side in the PowerBuilder 2017 folder (PB.exe is the running application when running from the IDE).

BUT

Here are issues we are encountering.  Wondering if there are fixes or possible work-arounds

Since each Release has its own unique .NET Assembly context,  we need to swap the .NET assembly context in and out of the PB 2017 folder when changing workspaces.  

1)  The IDE does NOT release OLEObject (even after Disconnect and Destroy) following an IDE run.  It keeps the assembly locked until the IDE is shut down.  We can't over write or delete assemblies following a run until the IDE is restarted.  This is an IDE flaw.  

2) There is no IDE hook to automatically run an external BAT or configuration process when a workspace is changed.  Context changing has to be done outside of PB.  I wrote an app object Open script to do the swap on startup in an IDE run - but it often fails due to issue 1 (locked object)

3) Since there is only one PB.EXE, it is potentially confusing to run multiple IDE instances simultaneously in different workspace contexts

Anyone have insight or prior experience that might shed light on our situation?

 

Thanks

Yakov

 

 

Roland Smith Accepted Answer Pending Moderation
  1. Saturday, 30 November 2019 19:40 PM UTC
  2. PowerBuilder
  3. # 1

There are several places in the IDE where it doesn't release files that are no longer being used.

If you add a new library and put some objects in it and later remove the library from the target, you cannot delete the .pbl file in File Explorer because the file is locked.

If I remember correctly, the same thing happens when assigning an image file to a picture control.

 

Comment
  1. Miguel Leeuwe
  2. Monday, 2 December 2019 07:37 AM UTC
For your scenario 2) ... Could a file unlocker tool help? For example this one allows commandline execution: https://www.4dots-software.com/freefileunlocker/

  1. Helpful
  1. Roland Smith
  2. Monday, 2 December 2019 14:06 PM UTC
Exiting the IDE releases the lock in my case.
  1. Helpful
There are no comments made yet.
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Saturday, 30 November 2019 01:52 AM UTC
  2. PowerBuilder
  3. # 2

Hi,

About "3) Since there is only one PB.EXE, ....."

I just found out (pb2019 r2 beta), that you can copy pb.exe to pb_workspace1.exe and pb_workspace2.exe.

You then can open multiple instances of pb at the same time.

If you open a different workspace for each one of them, each one seems to remember correctly the last assigned ws after reopening it. I have "Tools > System Option > Workspaces tabpage: "Reopen workspace at startup" checked.

Could this maybe give you some kind of a solution?

regards,

MiguelL

Comment
  1. yakov werde
  2. Monday, 2 December 2019 18:27 PM UTC
Hi: Thanks. Putting 201*7* R2 in the workspace folder and launching it does NOT cause the desirable behavior you described. I suspect that the behavior you describe is due to "the new assembly importer of PB 2019 R2 " Armeen describes below. Our shop is currently at 2017 R2
  1. Helpful
  1. Miguel Leeuwe
  2. Tuesday, 3 December 2019 02:59 AM UTC
Hmm, I guess you're right. We are also still on 2017 R3, but at home I use the beta. If that's the case most probably this will stop working when no longer a beta.

Sorry I

I tried the manifests myself (and got it to work), but found it more cumbersome than just using the good old registry entries. We don't have many updates on our ActiveX though, so for us it's not a problem.
  1. Helpful
There are no comments made yet.
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Friday, 29 November 2019 20:12 PM UTC
  2. PowerBuilder
  3. # 3

Hi Yakov;

   For issue #1 .. this has been a long time PB issue when utilizing OLE controls from way back to the SAP => Sybase => PowerSoft days of PB. Since the Appeon PB 2017 (and higher) IDE is built upon the PB12.6 code from SAP, the same limitation still exists. The current Ticket #1717 reflects this issue for visual OLE controls but memory issues also exist for OLE Servers (NVO's) as well.

    For issue #2 - correct, there are no hooks for that. The same when you run a "Deploy" from the Project Painter or perform a PBC compile. This feature and my "deployment" scenarios in need of executing a BAT file would be a "enhancement request" IMHO. We did have "BAT" file support in the Sybase .Net Winform & WebForm projects in the PB IDE under the Sybase versions of PB (11.5 => 12.5.1). Then of course, these target types were removed. But, the BAT file feature was great for many uses like you describe.

     I am not sure/clear of the restriction(s) you are referring to in item #3. Could you explain that issue further (for us Friday people running out of caffeine)?  ;-)

  Regards ... Chris

Comment
  1. Brad Mettee
  2. Saturday, 30 November 2019 14:33 PM UTC
Being able to execute an external command after a compile would be helpful for code signing too.
  1. Helpful
  1. Olan Knight
  2. Sunday, 1 December 2019 01:23 AM UTC
Have you looked at INNO SETUP v5 for compiling your PB code? It has the option of issuing a post-compile command.



Olan
  1. Helpful
  1. Roland Smith
  2. Monday, 2 December 2019 14:08 PM UTC
I use INNO for creating setups, I didn't know you could use it to build executables.
  1. Helpful
There are no comments made yet.
Armeen Mazda @Appeon Accepted Answer Pending Moderation
  1. Friday, 29 November 2019 20:03 PM UTC
  2. PowerBuilder
  3. # 4

Hi Yakov, Are your assemblies visual or non-visual?  If non-visual, you can use the new assembly importer of PB 2019 R2 and directly call the assemblies without COM workaround.  https://youtu.be/kmzvjQ6yI-Y?t=313

Comment
  1. yakov werde
  2. Monday, 2 December 2019 18:35 PM UTC
Thanks Armeen. This looks promising. Unfortunately we need a "today" solution. As you well know, large IT shops with big applications move slowly in adopting platform updates.
  1. Helpful
  1. Armeen Mazda @Appeon
  2. Monday, 2 December 2019 18:48 PM UTC
Oh I see. Hopefully somebody else on older version has a workaround for you.
  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.