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