I'm trying to use a class from a .NET dll library, which has no default constructor but has other overloaded constructors. It's not letting me define a variable.
Any ideas?
I don't know why your focused on whether the class has a constructor or not. This has nothing to do with whether you can define a variable of that class type. What .NET dll is it? I'm guessing you don't have the .NET dll in an assemblies.xml file. The .xml file needs to live in your work directory or it can be somewhere else but then you have to use the -assemblies startup parameter. Also if the assembly is not in the GAC, it needs to be in the same directory as the .xml file that -assemblies points at.
I don't see the problem?
DEFINE VARIABLE myObject AS SomeNetType NO-UNDO.
ASSIGN myObject = NEW SomeNetType(/*parameters here*/).
Class name?
OE version?
Sorry. My fault.
I keep forgetting that PDS is an application that requires fully loading a DLL before it can use it. My computer was missing the VC++ 2013 Redistributable, so PDS is not able to load all the dependencies of my DLL.
It's quite different from how Visual Studio reference DLL, which normally just need knowing the DLL signature during design-time.
Not sure why you're saying that. PDS does not load dependent Dlls. Windows loads them. This is not different from how Visual Studio works. If you are missing a dependency on your machine, your dll won't work, period.
PDS does not load dependent Dlls.
>> PDS only let me used the class name after I installed all the dependencies. This might have something to do with static linking since I am dealing with a DLL written in VC++ even if it is compiled as CLR dll instead of MFC dll.
This is not different from how Visual Studio works.
>> I always try using any custom DLL in Visual Studio 2010 and 2013 first before using it in PDS for sanity check. For my case, I can in fact compile my VS project without the VC++ Redistributable installed on the machine. This is expected because you can just-in-time load dependencies through event mechanism provided by the .NET framework. The executable only fails during run-time.
I would guess that VS is loading the assembly in a Reflection-Only context. Reflection-only context means you cannot execute the assembly. OE does not do this, the expectation is that you will run the code eventually. If you have a use case where you just want to develop your code without executing it, please request an enhancement.
No use case for Progress side yet since, for the most part, I use Visual Studio to create an executable for chasing down dependency issues because of available tools like Assembly Binding (fuslogvw), Dependency Walker and Process Monitor. I was just not expecting PDS not to recognize the class on the get go after testing things out in Visual Studio.
Thanks