Subscribe via RSS
Toggle Submenu
  1. Categories
  2. Recent
  3. Tags
View Replies (6)

Resolved Using a REGISTRATION-FREE .Net DLL in PowerBuilder

  1. Issue
0
Votes
Undo
  1. Marc Schmidtmayer
    Marc Schmidtmayer
  2. PowerBuilder
  3. Wednesday, 6 December 2017 12:10 PM UTC

I created a .Net DLL (COM) and managed to use it in PowerBuilder (12.5 Classic)... so far so good...

The downside that we need te register this DLL in order to be able to use it.
I've read that there's possibility to use such a DLL without registration: this via the creation/use of manifests.

Can anyone help me on this and explain what I need to do (and how) in order to be able to use the Net DLL (COM) in PowerBuilder without registration?
Any examples maybe?

The things I've (already) read are not really clear/straightforward: I can't make it work at the moment... sad

Anyone with experience with this (and willing to help)?

Thanks in advance,
Marc.

 

  1. COM
PB 2019 Migration Failure to Launch...
Outer Join syntax from PB to ANSI
Responses (6)
Aron Cox
Aron Cox Accepted Answer Pending Moderation
  1. Thursday, 22 August 2019 19:02 PM UTC
  2. PowerBuilder
  3. # 1

Just to be clear, as has already been stated, side-by-side works very well. It's a bit tricky to setup, I use GENMAN32 to embed all the necessary stuff in the .NET dll which has been compiled as a COM callable dll, along with a manifest file for the PowerBuidler application. No need to use REGASM, or do any intallation other than placing the dll along-side the executable and its manifest file.

Comment
Miguel Leeuwe
  1. Miguel Leeuwe
  2. Thursday, 22 August 2019 20:27 PM UTC
Hi Aron, yes I opted for the same solution and it worked for a simple dll. Things got more complicated when having a dll with lots of dependencies, so that's where I came to the conclusion that the "old" way was more transparent

Then another thing is that you HAVE to compile with the manifest option marked in you project file. Every compile it will be overwritten, so you have to back it up and restore constantly.

Thanks for you input though.

regards,

MiguelL
  1. Helpful
Aron Cox
  1. Aron Cox
  2. Friday, 23 August 2019 10:05 AM UTC
Hmm, I have a dll tgat has alof of dependencies to things like word / excel / outlook interop, web stuff, windows forms stuff, zip, ini, registry, encryption stuff from nuget and all I have to do is ensure all the dlls get copied into the same folder as the main one. It hasn't been any trouble at all. For which I am very grateful!!!



Also once I got my project setup correctly in Visual Studio I've never had to back up / restore anything to make it work it just works. I go in, make some changes, write some tests, do a build and copy all the files from the build to the same folder as my application. I may then have to update the version number in the maifest file to match, and it all works. I do have a bat file that's called int he post-build event to call GENMAN32 to do all the COM manifest stuff, but that was really the only tricky bit to get working.
  1. Helpful
Miguel Leeuwe
  1. Miguel Leeuwe
  2. Saturday, 24 August 2019 13:21 PM UTC
Those might be easier to be found, since they're already registered in windows.

My dependencies are some of our own DLL's which wrap up some other stuff. Maybe I'll give it another go in the future when I have some time :)
  1. Helpful
There are no comments made yet.
Miguel Leeuwe
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Wednesday, 21 August 2019 20:38 PM UTC
  2. PowerBuilder
  3. # 2

... and that's when you get no more answers ... same thing happened to me, but there's no obligation for anyone to respond of course.

I've had similar questions and as it turns out: it's less problematic to just stick to the old way of using the registry and even better: wait until appeon makes it possible to call .net assemblies without having to register them. (only non visual of course ....)

 

Comment
Load more comments
Miguel Leeuwe
  1. Miguel Leeuwe
  2. Thursday, 22 August 2019 20:29 PM UTC
Hi Armeen,

Not really a problem since I like C# a lot better.

We do have some DLL's written in VB .net. Is it not supported for the initial release or is VB never going to be supported?

Are we going to see the same support for Visual assemblies in the future?



regards
  1. Helpful
Armeen Mazda @Appeon
  1. Armeen Mazda @Appeon
  2. Friday, 23 August 2019 16:01 PM UTC
It would depend on demand, but our take on things is that Microsoft is going to moving C# forward over VB.NET so currently there are no plans for us to support other .NET languages besides C#.



However, you could create a C# proxy object/adapter to the VB.NET project and have PowerScript call that C# proxy object/adapter which in turn calls the VB.NET.
  1. Helpful
Miguel Leeuwe
  1. Miguel Leeuwe
  2. Saturday, 24 August 2019 13:22 PM UTC
That's very nice, I didn't know about the possibility of "C# proxy object/adapter to VB .net". I'll have a look at that when G2 comes out.

Thanks again.
  1. Helpful
There are no comments made yet.
Marc Schmidtmayer
Marc Schmidtmayer Accepted Answer Pending Moderation
  1. Tuesday, 12 December 2017 16:03 PM UTC
  2. PowerBuilder
  3. # 3

Hi Bruce,
Thanks for taking the time to answer... really! yes

I checked out your video and things are less 'cloudy'.
This is what I understood from this... can you tell me if I'm correct please?
So:
(1) generate the PowerBuilder exe with an external manifest
(2) generate a manifest for the assembly (.net dll) with the 'Side by Side Manifest Maker'
(3) add the info of generated assembly manifest to the PowerBuilder exe manifest
This way the GACUTIL and REGASM aren't necessay anymore.
Correct?

Just this as 'vagueness':
(A) Are the options for generating the PowerBuilder manifest of any imporrtance (" as invoker", "highest available", ... + "allow access to protected system ui")?
(B) Is the GUID still of any importance since no registration is necessary?
(C) Is it of any importance of the assembly is signed (or not) for this solution?
(D) I guess that the assembly should be located in the same folder as the PowerBuilder exe? If not, how will the exe find the assembly?
(E) Is there a possibility to get the manifest back into the PowerBuilder exe? Or not possible since the 'bootstrap'-thing?

Sorry about all this...
Just trying to understand... blush

Thanks again,
Marc.

Comment
Aron Cox
  1. Aron Cox
  2. Thursday, 22 August 2019 19:08 PM UTC
Yes, I don't use Side by Side Manifest Maker but instead use GENMAN32 which makes it all pretty easy to do but I guess the principle is the same.



I believe the enbedded manifest files mimic the registry setting so the GUID is probably still used, though it probably doesn't have to be unique. However the dll can still be registered with regasm should anyone want to do so, so I would still use it as it it was a non-side-by-side COM dll to aloow the choice of how to use it.



I have never signed an assembly, so I guess it's not important to get this to work :)



Yes, I have always had to put the assembly in the same folder as the executable, I guess it may be possible in the manifest file to point to a folder, but I haven't seen anyone ever do that.



As far as I know the manifest file will alway be separate from the PowerBuidler application, but I've found that quite useful as the version number in there allows you to control which version of the assembly it is expecting to find, and for a quick bug fix sometimes its nice to be able to update the manifest file with a new version number
  1. Helpful
There are no comments made yet.
Bruce Armstrong
Bruce Armstrong Accepted Answer Pending Moderation
  1. Wednesday, 6 December 2017 16:53 PM UTC
  2. PowerBuilder
  3. # 4

You might want to look at this:

https://community.appeon.com/index.php/articles-blogs/tips-tricks-techniques-articles/17-powerbuilder/167-calling-net-components-from-powerbuilder-via-com-wrappers-redux

That articles actually a bit old though (10 years according to the post on the article).

I did a session on the topic at Elevate 2017 that is much more current.  The video is here:

https://www.appeon.com/developers/library/videos/using-net-nonvisual-assemblies-powerbuilder.html

Comment
Marc Schmidtmayer
  1. Marc Schmidtmayer
  2. Tuesday, 12 December 2017 16:03 PM UTC
-----

  1. Helpful
There are no comments made yet.
Ashutosh Varshney
Ashutosh Varshney Accepted Answer Pending Moderation
  1. Wednesday, 6 December 2017 14:11 PM UTC
  2. PowerBuilder
  3. # 5

See if this helps:

https://weblog.west-wind.com/posts/2011/oct/09/an-easy-way-to-create-side-by-side-registrationless-com-manifests-with-visual-studio

Comment
Bruce Armstrong
  1. Bruce Armstrong
  2. Wednesday, 6 December 2017 16:55 PM UTC
Thumbs up.   Rick Strahl's blog is the place to turn to when I run into problems (like the manifest caching issue I'd forgotten about).

  1. Helpful
Marc Schmidtmayer
  1. Marc Schmidtmayer
  2. Thursday, 7 December 2017 12:47 PM UTC
Thanks for your reply.

Found this article earlier but didn't try it out since it is the other way round: try to use an external DLL within .NET and I wan't to use an .NET DLL in PowerBuilder.

But will check it out again...

  1. Helpful
There are no comments made yet.
Michael Kramer
Michael Kramer Accepted Answer Pending Moderation
  1. Wednesday, 6 December 2017 13:06 PM UTC
  2. PowerBuilder
  3. # 6

Hi Marc,

AFAIK, registration is required for the COM Callable Wrapper to work. PB uses OLE Automation to talk to the COM Callable Wrapper which in turn calls across the Win32 <=> .NET barrier.

There may be alternatives that I haven't used, but as I see it: You need registration to use COM interoperability between PB Classic and .NET.

 

/Michael

Comment
Marc Schmidtmayer
  1. Marc Schmidtmayer
  2. Thursday, 7 December 2017 12:47 PM UTC
Thanks for answering Michael.

  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.