By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,771 Members | 1,685 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,771 IT Pros & Developers. It's quick & easy.

Reference different versions of an ActiveX-dll

P: n/a
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
Apr 18 '06 #1
Share this Question
Share on Google+
5 Replies


P: n/a
"Michael Maes" <mi**********@community.nospam> wrote in message
news:D8**********************************@microsof t.com...
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


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

--
Ken Halter - MS-MVP-VB (visiting from VB6 world) - http://www.vbsight.com
Please keep all discussions in the groups..
Apr 18 '06 #2

P: n/a
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
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

--
Ken Halter - MS-MVP-VB (visiting from VB6 world) - http://www.vbsight.com
Please keep all discussions in the groups..

Apr 18 '06 #3

P: n/a
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.

Apr 19 '06 #4

P: n/a
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

""Peter Huang" [MSFT]" wrote:
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.

Apr 19 '06 #5

P: n/a
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/is...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.

Apr 21 '06 #6

This discussion thread is closed

Replies have been disabled for this discussion.