|
web
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Reference different versions of an ActiveX-dllWe 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
Show quote
Hide quote
"Michael Maes" <michael.maes@community.nospam> wrote in message No real help here but I'm wondering.... why not have one DLL that exposes news:D83FE7D7-040F-48CB-9B96-0EE160A8610A@microsoft.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 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.. 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 Show quoteHide quote > 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.. > > > 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 Show quoteHide quote ""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. > > 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. 
Other interesting topics
|
|||||||||||||||||||||||
