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
------------------------------

Have you put the path to the dll in the [user_3gl] asn section?
Iain


Sent from my iPad

Have you put the path to the dll in the [user_3gl] asn section?
Iain


Sent from my iPad

I did try to add the file in the [user_3gl] section in the ASN file. Didnt seem to help.

------------------------------
Tim Colvin
Smyth Retail Systems Inc.
Alliance OH US
------------------------------

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
------------------------------

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
------------------------------

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
------------------------------

I used VB.NET 2022 to develop the DLL.  It had been registered at the time the DLL was built.  I confirmed this by looking for the DLL in the registry and verified the type library, the GUID that was generated during development, and the location of the file at the time of registration. 

I mentioned /pid only because that was the method I had used to get the file imported.  I had tried without /pid and using the name of the DLL file to import, per the documentation (/sti /mwr=com C:\\testdll\\testdll.dll) and that errored out.  So I tried /pid and the type library based on the DLL I developed.  Before moving the file to usysbin, I would get an error when attempting to import that the class was unregistered.  As soon as I moved the file to usysbin, the class would import.  I was attempting to follow what was in the Uniface help documentation.  If there is better documentation on best practices when importing COM objects, I'd love to have access to it. 

I'll take a look at it with process monitor and see what additional information it gives me.  It may lead to a clue.

Thanks for your help.

------------------------------
Tim Colvin
Smyth Retail Systems Inc.
Alliance OH US
------------------------------

I used VB.NET 2022 to develop the DLL.  It had been registered at the time the DLL was built.  I confirmed this by looking for the DLL in the registry and verified the type library, the GUID that was generated during development, and the location of the file at the time of registration. 

I mentioned /pid only because that was the method I had used to get the file imported.  I had tried without /pid and using the name of the DLL file to import, per the documentation (/sti /mwr=com C:\\testdll\\testdll.dll) and that errored out.  So I tried /pid and the type library based on the DLL I developed.  Before moving the file to usysbin, I would get an error when attempting to import that the class was unregistered.  As soon as I moved the file to usysbin, the class would import.  I was attempting to follow what was in the Uniface help documentation.  If there is better documentation on best practices when importing COM objects, I'd love to have access to it. 

I'll take a look at it with process monitor and see what additional information it gives me.  It may lead to a clue.

Thanks for your help.

------------------------------
Tim Colvin
Smyth Retail Systems Inc.
Alliance OH US
------------------------------

I think I figured out the issue.  It had everything to do with the registration process of the DLL.  Since the DLL was written in VB, it has to be registered using the 'regasm' tool, which registers .net assemblies.  The next step is to add the registered assembly to the "Global Assembly Cache", where it is supposed to be accessible to any COM client.  I didnt do this step - because I didnt know about it.  The alternate method is to use the /codebase switch if you choose not to add it to the global assembly cache.  Once I registered the DLL properly, Uniface imported the DLL successfully, without me having to move it to the usysbin directory.  Additionally, my Uniface programs that call out to the DLL worked successfully as well. 

It is interesting though that if a DLL isnt registered, if you place it in usysbin, Uniface will still let you use it.  Im sure there are limitations to this, but at least in this test, it seemed to allow me to interact with the DLL, even though it wasnt registered properly.

Thanks for all the input and clues to help me get to this conclusion.

------------------------------
Tim Colvin
Smyth Retail Systems Inc.
Alliance OH US
------------------------------

I think I figured out the issue.  It had everything to do with the registration process of the DLL.  Since the DLL was written in VB, it has to be registered using the 'regasm' tool, which registers .net assemblies.  The next step is to add the registered assembly to the "Global Assembly Cache", where it is supposed to be accessible to any COM client.  I didnt do this step - because I didnt know about it.  The alternate method is to use the /codebase switch if you choose not to add it to the global assembly cache.  Once I registered the DLL properly, Uniface imported the DLL successfully, without me having to move it to the usysbin directory.  Additionally, my Uniface programs that call out to the DLL worked successfully as well. 

It is interesting though that if a DLL isnt registered, if you place it in usysbin, Uniface will still let you use it.  Im sure there are limitations to this, but at least in this test, it seemed to allow me to interact with the DLL, even though it wasnt registered properly.

Thanks for all the input and clues to help me get to this conclusion.

------------------------------
Tim Colvin
Smyth Retail Systems Inc.
Alliance OH US
------------------------------

Good to hear that it is working now. I was about to create a reply with regards to using regasm and the other stuff, but I was distracted by other support-related matters.

------------------------------
Daniel Iseli
Principal Technical Support Engineer
Uniface Services
Rocket Software, Switzerland
------------------------------