Reference different versions of an ActiveX-dll

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi,
We have an ERP-Application that needs to interact with an "external
accountancy program". This is acchieved through a "Connector" (ActiveX-dll)
so kindly provided by the Accountancy-Program.
Our issue however is that there are multiple (current) versions of that
connector, each one working only with a certain version of the installed
accountancy-program.
Of all current versions we use shared (I mean available in all versions, I
don't mean 'Static') methods. So all methods we call are available in all
Connector-Versions.
We do have multiple customers working with multiple versions of that program.
As it is impossible for us to force every customer to a certain version,
certainly not all on the same date, we need to make the referenced ActiveX
kind of "Version-Insensitive".

What would be the best way to accomplish this?
Would it be possible to have this and still keep Intellisense work on that
Interop? (StronglyTyped)

Creating a build for each individual customer is not an option.

TIA,

Michael
 
Michael Maes said:
Hi,
We have an ERP-Application that needs to interact with an "external
accountancy program". This is acchieved through a "Connector"
(ActiveX-dll)
so kindly provided by the Accountancy-Program.
Our issue however is that there are multiple (current) versions of that
connector, each one working only with a certain version of the installed
accountancy-program.
Of all current versions we use shared (I mean available in all versions, I
don't mean 'Static') methods. So all methods we call are available in all
Connector-Versions.
We do have multiple customers working with multiple versions of that
program.
As it is impossible for us to force every customer to a certain version,
certainly not all on the same date, we need to make the referenced ActiveX
kind of "Version-Insensitive".

What would be the best way to accomplish this?
Would it be possible to have this and still keep Intellisense work on that
Interop? (StronglyTyped)

Creating a build for each individual customer is not an option.

TIA,

Michael
Click to expand...

No real help here but I'm wondering.... why not have one DLL that exposes
properties/methods that make it specific to a customer? What you have there
surely sounds like the road to DLL hell. I'm not sure how dotNet handles
late binding (CreateObject, etc) but you can "make it work" as long as the
methods and their arguments are equal in all versions (still a nightmare in
the works imo). fwiw, in VB6, we've been dealing with multiple versions of
Office typelibs for years by using late binding (and losing Intellisense)

Personally, I'd create a single DLL and use properties to make it 'customer
specific'

Binary Compatibility
http://www.vbsight.com/BinaryComp.htm
 
Hi Ken,

I think I have to use reflection in this matter (Loading assemblies by
reflection) but then I loose IntelliSense and pay a performance-penalty (in
..Net 1.1 - I think that penalty is greatly reduced in .Net 2.0).
Since (currently) all required Methods & Signatures are equal, there
shouldn't be a big issue there.
I however want some more (and different) oppinions on this.
As to .Net itself, versioning is handled quite elegantly. You can even have
multiple versions of an Assembly side-by-side in the GAC (Global Assembly
Cache).

Anyone else some more advise?

TIA,

Michael
 
Hi Michael,

As your said, the .NET dll can have multiple version in the means.
But for the COM DLL(ActiveX), there registered only one version, that is
why the DLL hell occurred
So for your scenario, the reflection should be one way.
otherwise, as Ken suggestion, I think you may try to build another DLL to
wrap the ActiveX to isolate the customer.
e.g.
You can wrap certain method via
DoSomething(version)

Best regards,

Peter Huang

Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Hi Peter,

Thanks for your reply.
Could you please elaborate this a bit further.
How can I create a wrapper and become version-independent in .Net?
I have to reference the original COM in every poject I use the wrapper?
Maybe I'm mixing .Net with COM wrappers...
Could you please provide me a basic example for this technique.

Kind regards,


Michael
 
Hi

Thanks for your posting.
Here now we have two options.
1. Go the pure .NET way, so that there are no ActiveX. .NET support side by
side assembly which did not need to registered into registry.
2. Build an ActiveX which will expose all the method you need, and then
wrap the ActiveX in a .NET wrap. When different customer tried to call the
method, we can use the .NET wrap to redirect to different ActiveX call.
Because ActiveX is not side by side, it must be registered in registry
globally.
3. For XP and 2003 we have new option about side by side COM in win32.
Here is a link for your reference, but that way have some limitations.
Simplify App Deployment with ClickOnce and Registration-Free COM
http://msdn.microsoft.com/msdnmag/issues/05/04/RegFreeCOM/
Commonly if it is not necessary, we did not recommend your go this way.

Best regards,

Peter Huang

Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Back
Top