1. Gary Eden
  2. PowerBuilder
  3. Friday, 6 November 2020 11:09 AM UTC

Hi,

 

I'm just starting to use the .net dll importer and it seems to do what I need it to do. I've now progressed to the next step of deploying the application. This is my first stumbling block as the application seems to be looking in the directory that the application is started in, it does not attempt to look in the path that we have all the PB 2019 dlls located and where i have placed the .net dll. I have managed to work around this by determining the assembly path at runtime and setting it in the of_createondemand. This has worked in a locally deployed application so should be fine however it feels a bit clunky.

I would just like to know if others have had this issue or am I doing something wrong that is creating this additional code requirement?

 

Thanks

Gary

 

Accepted Answer
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Saturday, 7 November 2020 02:23 AM UTC
  2. PowerBuilder
  3. # Permalink

I think you're doing it correctly.

The importer tool will put a 'fixed' path in is_assemblyPath, so that's no good for installed applications.

I use the constructor event to set it (pointing to a subfolder of wherever the EXE has been installed.

Comment
There are no comments made yet.
Mark Lee @Appeon Accepted Answer Pending Moderation
  1. Monday, 9 November 2020 09:11 AM UTC
  2. PowerBuilder
  3. # 1

Hi Gary,

Currently, this feature is designed this way.

I suggest you use a relative path in the .NET DLL Importer module to avoid this issue. You can refer to the following link:

https://community.appeon.com/index.php/qna/q-a/dotnetassembly-loadwithdotnetframework-load-dll-from-gac

Please note that running this case in a PB IDE environment requires the relevant DLLS to be copied to the current PB project directory as well.

Or you can modify the is_assemblypath value of the import object manually in the Declare Instance Variables tab.

And you can also adopt Miguel’s suggestion.

 

Regards,

 

Comment
  1. Gary Eden
  2. Monday, 9 November 2020 12:15 PM UTC
Hi Mark,



We tried the relative path but it only seemed to pick up the dll if it is in the exe directory. I would have expected it to use the windows path to locate the dll if it cannot find it in the local directory but that did not seem to happen. Also noticed when run from a shortcut on the desktop it would not pick up the dll when in the same directory as the exe.

In the end we went down the route of modifying the is_assemblypath at runtime and that seems to be working for us. I was just wanting to confirm that this was expected behavior, which Miguel has done.



Thanks

Gary
  1. Helpful
  1. Mark Lee @Appeon
  2. Tuesday, 10 November 2020 02:54 AM UTC
Hi Gary,



According to my test verification, if using the relative path, both dll in the same folder of exe and in the subfolder of where the exe is installed work, but for which the relative path settings are different.

If it’s not behaving like this, please report a bug in our ticket system and provide a relevant case when you submit the ticket.



And it’s not supported to use the windows path to locate the dll.



Also, for the "Also noticed when run from a shortcut on the desktop it would not pick up the dll when in the same directory as the exe." issue, I can't reproduce it on our side, kindly please report this problem to our ticket system: https://www.appeon.com/standardsupport/newbug so it can be properly received and tracked. Please also provide a sample PB test case (with PBT / PBL) when you submit it to the ticket system.



Regards,
  1. Helpful
There are no comments made yet.
Gary Eden Accepted Answer Pending Moderation
  1. Monday, 9 November 2020 07:56 AM UTC
  2. PowerBuilder
  3. # 2

Thanks for letting me know, nice to have peace of mind.

Comment
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.