Question
Fifth Third Bank Bank
US
Last activity: 29 Nov 2017 11:44 EST
Can Pega Studio plugin consume .NET DLL that is NOT based on ComponentModel?
Is it possible for Pega Studio plugin to consume a .NET assembly (DLL) that is NOT based on ComponentModel? I ask because the only references to this topic I could find are posts like the following :https://pdn.pega.com/community/product-support/question/use-class-libraries-developed-net-openspan-automation
I would like to access a class library developed to do some processing against an external API. It seems like the most logical way to access its methods would be to utilize a Pega script component. While I am able to make a reference (via "Edit References") to the DLL, the script fails validation because it doesn't recognize the namespaces.
I am using Visual Studio 2015 with the Pega Studio Plug-in 8.0.1045
***Moderator Edit: Vidyaranjan | Updated Categories***
Westpac Banking Corporation
AU
Hi,
Write wrapper class by inheriting Component and then add the DLL in OpenSpan installation folder (C:\Program Files (x86)\OpenSpan\OpenSpan Plug-in for Microsoft Visual Studio 2015) and add to toolbox items in Pega Robotics Studio to use those methods in automation.
Fifth Third Bank Bank
US
Thanks for your reply. However, my question was whether it is possible to use a DLL withOUT the use of Component. Are you saying the answer is no, it is not possible?
Westpac Banking Corporation
AU
Yes, we can't use the DLL if it is not component type.
Fifth Third Bank Bank
US
Turns out that is not true.
Accepted Solution
Unum
US
Not sure, but the following postings and links may be of use.
https://pdn.pega.com/community/product-support/question/c-pega-robotics
The one below is only of use if you are going to utilize the Openspan Script Componenet to write custom C# Methods for use in your automations.
http://help.openspan.com/52/Components/Script.htm
Fifth Third Bank Bank
US
ScottT32,
Thanks for the links. The second one had information that helped me resolve the problem. It turns out the simply changing the location of the DLL into the OpenSpan installation folder -- and then referencing it -- cleared up the problem where the namespaces were not recognized inside the Script component.
However, it doesn't make a lot of sense for OpenSpan to require this. It is not "clean" to require external DLLs to be put in the OpenSpan installation folder. We have several projects that will need to reference DLLs in this way. They are completely unrelated to each other, and we shouldn't have to clutter the installation folder on our development machines with DLLs that are not part of the core program. My two cents.
Pegasystems Inc.
US
You should also be able to place them in %AppData%\OpenSpan\PublicAssemblies, however that doesn't solve the problem of keeping them in one place. I agree it would be nice to reference them from anywhere.