With VB6 I used to set a reference to Extra.tlb in my app.   When I deployed the app I did not include this file and so my app would use whatever Extra.tlb that exists on the client PC.   This allowed my app to work with any version of Extra! (6.5 and above) without problems.

Now in C# after setting a reference to Extra.tlb and deploying my app only clients with exactly the same version of Extra as me can use it.   Everyone else get an invalid reference error.

I've searched Attachmate's site and Googled with no luck (apart from finding this forum).

How can I add a reference to Extra! in my C# app and enable it to work on any version of Extra?

Thanks in advance.

John

 

John,

  I did this through COM and DCOM.  I installed Attachmate and then registered Extra.tlb on the deployement target and local machine (for debugging and references).

  Look at regasm.exe and regsrv32.exe.

  Secondly you need to setup permissions (though I am somewhat vague on the exact specifications since documentation on this is incredibly sparse) on the DCOM and COM+ libraries.

  Look at dcomcnfg.  Just -> Windows -> Run -> DComcnfg.exe

You'll need to do this on both your client and deployment server.

In DCOMCnfg you'll need to mess with:
  Console Root -> Component Services -> Computers -> My Computer -> COM + Applications

 Then right click on COM + Applications click NEW and it will ask you to point to the tlb.

DCOM Config doesn't look like it is required but you will see an EXTRA.Sessions and EXTRA!.Session in there and you can set the credentials how you want.


Assuming you've done the above, just add a com reference to your VS project and it should work.

~Mike

One clarification the libraries may or may not be different with v 6.5.  I am using 7.1  but I imagine the setup is similar if not the same.

~Mike

The library is identical from Extra! ver 6.2 up to ver 7.1.
In Visual Studio when you add a reference to a libary it wraps the referenced file into an interop dll.  So Extra.tlb becomes interop.Extra.dll and this is included in the installation package for your app.  Your app will not run without it.

I've created installers for clickonce (installs to User\Local Settings\Apps\2) and a standard installer to C:\Program Files.  Also tried overwriting the client version with my Extra.tlb with no luck.

I wonder if when VS creates the interop dll it also references Extra.exe and gets its version number.

More experimenting needed..

John

 

John,

////WHAT/////
  There are really only two solutions, I believe, when dealing with this.  Either you reference on your solution each version of Extra and then write a version switch call routine for each method you need to call (typically done at the loading of your application and the wrapper would persist which version was called).  The other solution is an IPC (Interprocess Communication) solution where your reference is to the other process and you call (communicate) with that process in a uniform way and then it would ref the right version because it would be based on the client computer/server.  This second solution takes more time to setup, but because I know nothing of your environment or constraints its the most I can really help with.

////HOW////
  I use IPC here for different systems and its honestly somewhat of a pain to get setup but once it is there it works just fine.  You could consider the following ways for IPC; Shared memory map, GNP (Named pipe), service, WCF, sockets, etc..  Each are setup differently and have different pros/cons.  I typically lean to Sockets and Shared memory maps, but that is because of some constraints here.  You might consider a WCF on local.

  So you might ask how could you do this in practice?  Here are three options

1.) You can build a single solution to target each version.  Easy way to test may not work depending on attachmates install, it may not allow you to have multiple instances of attachmate on one pc.

2.) You use an IPC solution AND you build a .net solution for each version and your installer determines which version to put on your client machine target.

3.) You use an IPC solution AND you deploy your code to the target and compile on the target machine.

  Here I use #3 but for different reasons as there are many COM components *we touch many different backend systems* so the combinations involved in #2 just don't make sense.  and IPC is easy enough to do anyway I use sockets and shared memory maps.