What approach is the best to migrate PB classic application to be used in .Net application?

[Former Member]

Hi,

We are planning to migrate PB classic application to PB .Net so that some modules could be called in .Net development application.  I wonder the following structure will work in fulfilling the end result.

1. Create a new PB Assembly with all existing libraries (pbl)

2. Create a .Net Assembly

• Reference step 1's PB Assembly
• Create function to launch few modules/windows

3. Reference step 2's .Net Assembly in WPF/C# application and call function to launch modules/window

Thanks for any help,

Lam

[Former Member]

Hi,

Thank you for the reply.  I placed an embedded SQL query by returning a valid count of a table right after dw_1.retrieve() = -1 which means SQLCA works.

The following dlls are in Windows Form application bin\debug directory. 

Thanks again,

Christine

[Former Member]

FYI:  The PB .Net part of the run time DLL's need to be in the MS-Windows O/S's Global Cache.

Suggestion:  I would run the PB 12.6 Classic "Packager.exe" utility found in the PB "Shared" folder and let it create an MSI for you to properly install the PB run time DLL's.

HTH

[Former Member]

I did run Packager.exe as well.

[Former Member]

Hmmm ... I'm beginning to suspect a missing DataWindow Object. Can you check to make sure in your DWO is being deployed in your .Net Assembly project? You could try doing a simple Describe() function just before the Retrieve () to test if the DWO was really there & OK. Also make sure that your SetTransObject() worked as well.  

[Former Member]

Yes, you are right.  I get nothing returned from Describe().

How can I ensure DWO is being deployed in .Net Assembly project?  I could see the PB window opened in Window Forms application.

Christine

[Former Member]

   The PB project Painter during the "Deploy" should have created a PBD file for each PBL in your library list. The PBD's may/should contain the DW object(s) you need. When you deploy the .Net Assembly, you also need to deploy the PBD files as well located in the BIN folder.

[Former Member]

Hi Chris,

Once I placed the PBD file to the .Net Window Form application's debug folder, I could see the data in the DW.

Thank you,

Christine

[Former Member]

Wonderful news Christine!  

Yipppeeeee .....

[Former Member]

Hi Chris,

I am going to experiment on the approach using classic .Net Assembly target with one pbl of the non-visual object that exposes a function call to open a window with datawindow and another pbl including a window and datawindow objects. 

Then a dll is generated and is referenced in a testing Windows Form application where I have a window form with a button that open a PB window with data window control.  However, I keep getting -1 from dw_1.Retrieve().  Would I miss anything?

Thanks for any help,

Christine

[Former Member]

Hi Christine;

  There can be many reasons for a -1 on the retrieve. I would check the following ...

1) Did your CONNECT command work OK (zero return code)?

2) Is the DB Client available on the machine where your Windows Form application is running?

3) Did you assign a DW Object to your DataStore OK?

4) Was the DW Object actually deployed to your .Net assembly OK?

5) Did you issue a SetTransObject () method and was the return code OK?

6) Are the full PB run-time DLL's available where your Windows Form application is running?

HTH

Regards ... Chris

[ricardojasso]

Are you using the global transaction object SQLCA? If you do I suspect you shouldn't. Create and initialize a local transaction object to be used by your datawindow and try again.

[ricardojasso]

Mmmhh, I hadn't seen your post where you tested SQLCA in an embedded SQL getting a successful connection. So, just to clarify, are you testing using PowerBuilder.NET or using a C# application in Visual Studio?

[Former Member]

Hi,

I am experimenting on .Net Assembly on PB Classic and using the generated .Net Assembly on VS 2013 Windows Form application.

Christine

[ricardojasso]

Ok, this is all very interesting. Thank you for your answer Christine.

Ricardo

[Former Member]

You are better off deploying .Net Assemblies from the Classic IDE. As Chris said, the PB.Net IDE will likely be going away.

[Former Member]

First, thank for the replies.

If we are doing this .Net Assembly approach, are we going to migrate/move all existing pbls and have one pbl with the project object under .Net Assembly target?

Thanks,

Christine

[Former Member]

Hi Christine;

  You can have one or more PBL's in the .Net Assembly target - its up to you and what you find easier to manage. The key consideration of course, is having all the objects and their ancestors accessible in  order to compile & deploy the .Net assembly.

HTH

Regards ... Chriss

[Former Member]

Hi Christine;

  FWIW: Looks like PB.Net will no longer exist when Appeon takes over PowerBuilder very soon. I would personally not put any effort into migrating to PB.Net. Even if you do, its based on obsolete VS2010 and .Net 4.0 technology. AFAIK, Appeon has no plans for this product in its current road-map ... PB Vision and Roadmap Webcasts

Just my $0.02

Regards ... Chris