AnsweredAssumed Answered

VSA DCOM with VC++ .NET

Question asked by AdamV on Jan 28, 2011
Latest reply on Apr 22, 2011 by Joey

Like • Show 0 Likes0
Comment • 8

Hello,

I am trying to use the DCOM interface to the VSA software from a VC++ .NET application. I am encountering an error when attempting to import the library:

#import "..\..\..\Vector\VsaVector.exe"

I get a compile error:

"Error loading type library/DLL"

Has anyone else encountered this and solved it or have any suggestions on how to get around it? Is the DCOM interface not compatible with .NET?

Thanks,

AdamV

No one else has this question

Outcomes

8 Replies

andyowen Jan 28, 2011 9:01 AM
Mark Correct
Correct Answer
You say DCOM: are you trying to access the VsaVector.exe that is installed on a remote PC/instrument other than your development PC?

Also, I'm assuming that you replaced the ".." with the actual installed directory of the VSA software right? Here's the default installation directory (this works for COM: VSA installed on your development PC):

#import "C:\Program Files\Agilent\89600 VSA\Vector\VsaVector.exe"

This works with the C example in the VSA help file. I'm using VS 2010, BTW.
Like • Show 0 Likes0
Actions
AdamV Jan 28, 2011 10:19 AM
Mark Correct
Correct Answer
Basically I'm trying to do the same types of things that are done in the examples, except I want to control VSA software running on a different machine on the network.

I installed the VSA software on my development machine per the instructions in the DCOM readme. The path to VsaVector.exe is correct. I have tried it with both relative and absolute paths. It is finding the file, otherwise the compiler gives you a different error.
Like • Show 0 Likes0
Actions
andyowen Jan 28, 2011 10:50 AM
Mark Correct
Correct Answer
Is the path to the VsaVector.exe on the remote PC? From your last message, I assume that both PCs have valid installations and license?

Also, you might need to add the username (and possibly password) of your development PC to the target PC. Otherwise there could be some security issues that are preventing this from working.
Like • Show 0 Likes0
Actions
odanzy Jan 30, 2011 3:26 PM
Mark Correct
Correct Answer
Going along with Andy. You might try putting a quick VB script together just to make sure you have basic communication between the server and client. It could be a Windows security error that is keeping communication from going.
Like • Show 0 Likes0
Actions
AdamV Jan 31, 2011 5:11 AM
Mark Correct
Correct Answer
The path to VsaVector.exe is on the local development PC. Both PCs have the software installed, however, according to the README, the development PC does not need a license, and therefore, does not have one. My user account is setup the same on both PCs. I have run the connection test application that comes on the CD and it connected to the remote machine successfully. My application is not getting as far as attempting the connection. It won't even compile because it doesn't recognize the VsaVector.exe as a vaild import.
Like • Show 0 Likes0
Actions
andyowen Jan 31, 2011 6:28 AM
Mark Correct
Correct Answer
That's right: your development (client) PC does not need a license but I ask only to understand your configuration. And further, since it is not required to have a license, I don't think your program should be pointing to the local VsaVector.exe. The C example in the help is for COM and I have yet to try programming via DCOM but I have some ideas.

The "import" statement in the example is using the VsaVector.exe as the VSA type library but that is for the local (and unlicensed) installation. I have two ideas (but I don't have two PCs at the moment to try it out; perhaps later this week):

1) Try replacing that with the path to "VsaVector.tlb" type library from the "dcom" folder. This is this the type library used by the VsaDcomCnfg.exe and it is registered as part of the DCOM setup ("Install.bat").
2) Map a drive to the remote (server) PC's "89600 VSA" installation folder and use the path to the "VsaVector.exe" on the remote PC.

Try these and let us know if you are successful. I'll have to look into it a little further when I have an analyzer (PC with 89601) available.
Like • Show 0 Likes0
Actions
hbaugh Apr 18, 2011 3:09 PM
Mark Correct
Correct Answer
It was a dll registration thing, he registered all the VSA dlls and the program compiled.
Like • Show 0 Likes0
Actions
Joey Apr 22, 2011 4:46 AM
Mark Correct
Correct Answer
"
It was a dll registration thing, he registered all the VSA dlls and the program compiled.
"

Hi hbaugh,

Could you please elaborate the "dll registration thing"? What are those dlls that needs to be registered? And how? (use regsvr32 command?) Thank you!
Like • Show 0 Likes0
Actions

VSA DCOM with VC++ .NET

Outcomes

Related Content

Recommended Content