Posted: 22 Dec 2017 9:23 EST Last activity: 26 Dec 2017 14:35 EST
How to access .NET class library Properties.Settings from Pega/OpenSpan automation
Can a Pega/OpenSpan automation project use config file settings to change values used in "Properties.Settings" of a .NET DLL? I am trying to something similar to how one might set up a Visual Studio solution.
For example, a VS solution might have two projects: a web application project and a class library project. The class library project might have property settings, which enable type-bound references like "MyProjectNamespace.Properties.Settings.Default.MySettingName". Using Properties.Settings would generate entries in the app.config file something like that seen below. Then in the consuming web application project, the configSections and applicationSettings configuration elements would be copied/pasted into the web.config file.
My question is if something like this is possible with Pega/OpenSpan? For example, can the RuntimeConfig.xml file be modified in a way, so that the DLL from the .NET class library project would pick up new settings (e.g. - prod vs. dev)? Or, can an existing app.config be deployed in a way to be picked up by the solution? If so, please describe the correct procedure, or a viable work-around. I have tried adding the above settings (leads to error), and I have tried putting an app.config file in various locations including the location of the Pega project, and the Pega installation folder.
***Edited by Moderator Marissa to update SR Details***
Thank you for the quick reply. The OpenSpan.Runtime.exe.config did the trick. However, I did not use the AppSettings section, but rather added the "applicationSettings," along with a new config "sectionGroup," as described in my original post.
Upon opening that file, I recognized immediately that it was the same type of config file used in .NET apps. Your suggestion will save me a lot of time from otherwise having to re-factor the .NET class library project.
And yes, the SR number was related in the sense that it also dealt with the problem of consuming a .NET DLL, albeit the specific issue was different. Thanks again.