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

Resolved Generate .Net Assemblies in PB 2017 R2 - Failed to load asmpoc.dll because it is not a valid .Net Assembly

  1. Issue
0
Votes
Undo
  1. paulo gomes
    paulo gomes
  2. PowerBuilder
  3. Monday, 26 February 2018 16:52 PM UTC

Hi all,

I received the message "Failed to load asmpoc.dll because it is not a valid .Net Assembly" after the following steps using PB 2017 R2:

1. create a .Net Assembly target from an existing target

2. expose the methods in the Project Objects tab that pass/receive arguments that are .Net compatible data types

3. create the .msi file using the Project file; install the DLL and other files by running the msi generated

4. try to register the dll with windows registry using REGASM, and received the error message mentioned

Few questions:

1. how can the generated dll be used in a PB application? 

   1.1 do I need to registry with windows registry prior to call it from PB?

   1.2 do I need to registry it with the GAC prior to call it from PB?

   1.3 is it by default a COM visible?

2. does someone have an example generating a DLL in PB and calling it in PB? Remember, PB 2017 R2 does not have the PB .Net version anymore.

3. what is the point to have a .Net Assembly target in PB 2017 R2 if it generates a not a valid .Net Assembly (as the received message from REGASM) and cannot be registered or consumed?

I did not try to call this DLL using VS (C# or VB) but I don't thing that it is the direction I should go. Also this is a Proof of Concept and I have 1 DLL and 1 mothod to call but the real project has around 3,000,000 lines of code and close to 600 PBLs with hundreds of NVO to be exposed, which makes impossible to use anything else than the existing PB code. The existing code must be reused.

Any suggestions or ideas will be welcomed !

Thank you,

Paulo Gomes

Interval Leisure Group

Senior PB Team Member

  1. COM
  2. .NET Assembly
pbdom170.pbd and Native SVN
How to get tables to appear in Database painter fo...
Responses (3)
Bruce Armstrong
Bruce Armstrong Accepted Answer Pending Moderation
  1. Monday, 26 February 2018 19:09 PM UTC
  2. PowerBuilder
  3. # 1

Also

>>expose the methods in the Project Objects tab that pass/receive arguments that are .Net compatible data types

This may be your issue.  If you are going to make an assembly COM visible you need to use COM compatible data types, which is a very limited subset of .Net compatible data types:

https://msdn.microsoft.com/en-us/library/sak564ww(v=vs.100).aspx

Comment
paulo gomes
  1. paulo gomes
  2. Monday, 26 February 2018 23:09 PM UTC
Hi Bruce, thank you for the reply.



The trouble with regasm is that when you run it you assume it is running the latest version, which is in my case .Net 4.6.xxx. However by default it runs the exe that is in the .Net 2.0.xxx folder instead ! So I fixed it running the regasm that is inside the folder C:\Windows\Microsoft.NET\Framework\v4.0.30319 in my equipment. 



You said " ... I don't quite see the point of taking this approach ... " and it needs an explanation, that follows:



We already migrated last year our EA Server web application (front-end JBOSS/Java and back-end PB NVOs business logic) to IIS by converting the NVOs to .Net web service and deploying them into an IIS machine running windows 2012 R2 server.



What I meant by exposing the methods with .Net compatible data types is because the structure passed back and forth by the EA Server app has power objects, like result set, data store, result set error and so on, which cannot be exposed in a .Net component, like the ones generated by PB in the .Net Web Service target. So only methods receiving/returning simple data types (integer, string, etc) were exposed.



We finished the migration last year and all business logic and navigation is a copy of what happens in the EA Server app. So everything works fine. So why do we want to call PB .Net assemblies? Because the IIS version is too slow: basically 3 times slower than the EA server app: call .Net assemblies is a try to improve the performance.



I'm doing a Proof of Concept: call from PB the most time expensive bus logic task we have and compare the response time with the IIS app and EA Server app to determine where to go from there.



The web service is a SOAP service returning XML by default. We already changed that and it is returning JSON instead. We improve few seconds, but it is still too slow.



The Appeon road map to release PB 2018 with support to generate and consume RESTFUL web services is Dec-2018 that we expect to improve some how the performance. If calling .Net assemblies instead proves to be faster we will plan and execute de migration.



However, any ideas for other solution will ve very welcomed 



Thank you all,



Paulo



Interval PB Senior Team

  1. Helpful
There are no comments made yet.
Bruce Armstrong
Bruce Armstrong Accepted Answer Pending Moderation
  1. Monday, 26 February 2018 18:19 PM UTC
  2. PowerBuilder
  3. # 2

>>1.1 do I need to registry with windows registry prior to call it from PB?

You either need to use REGASM to create registry entries for them, or you need to create a manifest file for the assembly that contain the registry entries and package that with the dll.  PowerBuilder accesses the DLL through a COM wrapper, and it needs the COM registry entries to do that.

>>1.2 do I need to registry it with the GAC prior to call it from PB?

You either need to register it with the GAC or provide it as a side-by-side assembly.  Using a manifest file (see above) makes deploying it as a side-by-side assembly possible.  Note that the assembly is dependent on a number of PowerBuilder runtime assemblies.  They would also need to be added to the GAC or provided as side-by-side assemblies as well.

>>1.3 is it by default a COM visible?

No.   PowerBuilder generates .Net assemblies as non-COM visible.  The original intent of the .Net assembly was to use the result in a .Net application, which wouldn't need the COM registry entries and wouldn't need to be constrained by some of the limitations imposed on .Net assemblies that are meant to be COM visible.

You might try examining your assembly using FX cop (part of the windows SDK tools).  It shows you the assemblies your assembly is dependent on and the status of the COM visible attribute.

One workaround for this would be to use ILDASM to disassembly the assembly to IL, switch the COM visible flag in the IL and then use ILASM to recompile the IL to an assembly.

Also not that in order to be added to the GAC, the assembly would need to be strong-named.  That would require a code signing certificate, unless you're in the position to self-sign the assemblies.

Also, if you're just using standard PowerBuilder code in the .Net assembly, I don't quite see the point of taking this approach.  The reason you might want to create a .Net assembly (in any tool, be it PB or VS) and then use that in PowerBuilder through a COM callable wrapper is because you're using some .Net code in the assembly that PowerBuilder doesn't have direct access to.  That is, you would be using conditional code blocks in your PowerBuilder .Net assembly code to access .Net methods and then compiling that as a more friendly .Net assembly that PB can use.

 

Comment
There are no comments made yet.
paulo gomes
paulo gomes Accepted Answer Pending Moderation
  1. Monday, 26 February 2018 17:30 PM UTC
  2. PowerBuilder
  3. # 3

Hi, thank you for the reply.

The runtime DLLs were installed long time ago, so I still think this is a bug.

Thank you,

 

Paulo

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.