How exactly was the DLL registered on the system? And what kind of VB are we talking about? Is this .Net or the ancient VB6 stuff?
And why do you mention that you had to use the /pid switch in order to get the DLL imported? This is the "normal" way to do this. Uniface will instantiate the COM object using the PID and then query the interface in order to import the definitions. In case the DLL includes a type library then the DLL name (and location) can be specified (without /pid) in order to import the interface definitions directly from the DLL.
Still, when calling out to a COM object then the PID is used to instantiate the object. These information should be stored in the registry where Uniface is running (and it also includes the actual location of the DLL). Not sure why you would need to copy the DLL in to the bin directory of Uniface (i.e. usysbin). Unless the DLL has some dependencies that cannot be found anywhere else?
It might be an idea to use the Sysinternals tool
Process Monitor from Microsoft to see what kind of dependencies the DLL is missing. The tool will not only show you the file I/O, but also the registry access.
I hope this helps.
------------------------------
Daniel Iseli
Principal Technical Support Engineer
Uniface Services
Rocket Software, Switzerland
------------------------------
Original Message:
Sent: 05-09-2022 16:22
From: Tim Colvin
Subject: Importing .NET COM DLL's
I have a COM Class DLL I've written in VB that I wanted to communicate with via calls in Uniface (call out from Uniface to the DLL). The only way I could get the signatures to import was to have the DLL file in the uniface\common\bin directory, regardless of where the DLL was originally registered on the filesystem. Additionally, I had to use the /pid switch in order to get the DLL imported. If I then removed the DLL from the common\bin directory, the calls to the DLL would stop working (-150). Is there a way I can register the DLL to the system and call out to the DLL without hard coding the path somewhere or having the DLL in the uniface\common\bin directory? The DLL itself is working, I just need to understand my options for placement on the system outside of the uniface file structure, like so many other DLL's and controls.
------------------------------
Tim Colvin
Smyth Retail Systems Inc.
Alliance OH US
------------------------------