Hi!
I have to code custom controls in Visual Studio 10, build them as a DLL, then import them to OpenEdge Architect and use them there, but I've come across some problems.
Firstly, what version of the .NET-framework is OE using?
4.0 controls won't even be added to the list in "Browsed Assemblies", when you attempt to add controls to the toolbox. It pops up an error saying "The assembly <filenamehere> or some of its dependencies could not be loaded."
If you switch the target framework in VS to 3.5, you can add it to the "Browsed Assemblies" perfectly fine and it recognizes it, but once you check it and press "OK" to add it to the toolbox, it just adds a control named "TestModule", with an erroricon, and you can't do anything with it.
EDIT: To clarify: My control is NOT named TestModule in visual studio, this is something OE decides to call it after I add it to the toolbox, it has its proper name in the "Browsed Assemblies" list!
Is there something I have missed? The actual project I'm trying to add is just an empty usercontrol to test it.
I'm using:
OpenEdge Architect 10.2B02
Visual Studio 2010 Professional
Windows 7
Thanks in advance!
Nevermind, A restart of openedge did the trick. Weirdly.
.NET 4.0 is supported with OpenEdge 11
You'll have to have your custom assemblies in the same directory as the assmeblies.xml file, which is either specified by the -assemblies parameter or the session working directory (project root directory in OpenEdge Architect by default).
The assembly .DLL is in that directory, and now it works in OE Architect, syntax check passes etc. But now when I attempt to run it using a script in the Procedure Editor, it gives me error 5638 and says that my external class isn't defined. Think I yelled hello before I passed the bridge here.
How are you launching the Proc Editor? You'll also need to add -assemblies to the command line, if you haven't already.
-- peter
prowin32.exe -assemblies \\path\to\assemblies.xml-folder\ -pf \\stuffs\stuff -ininame \\another\stuff
I haven't put the DLL into the GAC, but the DLL is in the assemblies.xml-folder.
The script I run is basically what I always run when developing:
run startscript.p.
and startscript.p basically contains:
DEFINE VARIABLE r AS OurSystem.Root NO-UNDO.
r = NEW OurSystem.Root().
r:Initialize().
DELETE OBJECT r NO-ERROR.
prowin32.exe -assemblies
path\to\assemblies.xml-folder\ -pf
stuffs\stuff -ininame
another\stuff
If your
path\to\assembly points to a network folder you may run into security issues when your assembly is not digitally signed. Does is work better/different with a local assemblies path?
To keep thread updated for future users and to keep facts straight: I successfully managed to import the assembly reference over a windows network after I signed them in visual studio first, as well as add [assembly: System.Security.AllowPartiallyTrustedCallers] to my assembly info. But when I try to run my application, it errors when it calls my librarys functions, saying that the library doesn't allow partially trusted callers. This isn't because of the library though, it is because of a security setting in the .NET Framework Configuration Manager, something I cant access since I have installed .NET Framework 4.0, wich apparently deleted the "deprecated" tools from 3.5 and below. The error would probably go away if I build it with 4.0, but then I cant use it in OE since 10.2b runs 3.5.
It now works to run it with assemblies locally, but it's a hassle. Will look into a solution and answer if I find one.