1. yakov werde
  2. PowerBuilder
  3. Tuesday, 11 February 2020 17:54 PM UTC

We are moving to GAC-free COM InterOp.  

For our non-visuals we changed .NET class progIds, ClsIds and removed strong naming and generated internal assembly manifests. 

We changed the ProgID in our PB OLE ConnectToNewObject calls and all is well

BUT

We have homegrown visual ActiveX controls.  We can do the same ID modification trick on the .NET side.

BUT how do we modify visual form (uo or window) code to point to the new ProgID?  It's all binary encoded in the 'Hidden" binary section at the end of the source file?

Any experience or pointers are appreciated.

PS:  I understand there needs to be RegAsm for the IDE (design time) to find the visual  (yes the old painter is still calling REGSVR).  But that just generates the binary stuff and links the COMFORM to the IDE painter tool).  At runtime ProgId is the lookup key.

 

I'd like to swap the progid so it finds my local side by side version

 

Appreciate any insight

 

Yakov

DevOps & Sr Dev

OpenLink Financial

yakov werde Accepted Answer Pending Moderation
  1. Wednesday, 12 February 2020 18:19 PM UTC
  2. PowerBuilder
  3. # 1

Thanks Armeen

Management has been longing to free our flagship application from GAC and Registry dependency for years.

I started R & D and then active development months ago; long before 2019 R2 was announced.  When the announcement was made, management did not want to change direction based on not yet released functionality.

Also upgrading Appeon platform to a new release, is a big deal that management didn't want to undertake.

For all our non-visual services, we are now Side by Side both devtime in IDE (pb170.exe) and runtime Agtech.exe

I ported my prototype / test harness to 2019 and it continues to function

Question:  Forward thinking:  Is this mechanism at risk of failing in future releases?

Question  Many of our PB facing assemblies have other assembly dependencies (DevExpress runtimes etc).  How does this work with the Class importer?

 

Thanks for you answers

 

Yakov Werde

Devops and Sr Developer

OpenLink Financial, Agribusiness Division

Comment
  1. Armeen Mazda @Appeon
  2. Wednesday, 12 February 2020 18:25 PM UTC
I think there is not big risk for your approach to keep working in the foreseeable future because we do not plan to make any big architectural change to the client/server PowerScript-based project type of PowerBuilder.

As long as these are non-visual assemblies it should work with the C# class importer. I recommend you try a simple test case with the beta version, and if any problems please open a support ticket. You can get the beta here: https://www.appeon.com/developers/pb-2019r2-beta.html
  1. Helpful
There are no comments made yet.
Armeen Mazda @Appeon Accepted Answer Pending Moderation
  1. Tuesday, 11 February 2020 23:44 PM UTC
  2. PowerBuilder
  3. # 2

Hi Yakov,

For the non-visual .NET stuff, I really recommend you use the C# class importer instead of COM.  Although it is called C# class importer, we have customers that have confirmed it seems to work fine for any .NET language not just C#, for for example VB.NET.

Regards,
Armeen

Comment
  1. Armeen Mazda @Appeon
  2. Wednesday, 12 February 2020 03:28 AM UTC
Yes, it is PB 2019 R2 (not after). It is currently in beta, and scheduled to release in several weeks.
  1. Helpful
  1. Miguel Leeuwe
  2. Wednesday, 12 February 2020 03:40 AM UTC
Great news. This is going to make life so much easier :)
  1. Helpful
  1. Armeen Mazda @Appeon
  2. Wednesday, 12 February 2020 03:42 AM UTC
Glad you like! :-)
  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.
We use cookies which are necessary for the proper functioning of our websites. We also use cookies to analyze our traffic, improve your experience and provide social media features. If you continue to use this site, you consent to our use of cookies.