CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 9 of 9
  1. #1
    Join Date
    Jul 2008
    Posts
    42

    [RESOLVED] Clash of DLL versions in co-existing Products

    I describe my query as follows:

    1. We have a s/w vendor who delivers his SDK composed of DLLs to us.
    2. We use the DLLs supplied in our applications.
    3. I have 3 stand-alone desktop products being developed in VS 2005 using C++ language.
    4. Release cycle of these three Products are different and independent of each other.
    5. At any given point of time, there is every chance that Product 1 uses xyz.dll ver 1, Product 2 uses xyz.dll version 2, Product 3 uses xyz.dll ver 1. In fact, this is what is happening at present.
    6. Setting of /bin path to PATH variable is causing havoc as Product 2 is picking up xyz.dll ver 1 and hence crashing.
    7. Any suggestions to avoid this wrong picking is helpful to me.

  2. #2
    Join Date
    Sep 2004
    Location
    Holland (land of the dope)
    Posts
    4,123

    Re: Clash of DLL versions in co-existing Products

    Welcome to the so called 'DLL hell'. Your problem is the biggest problem MS has with its DLL construction. You could add some sort of version number to your dll. This is the way how linux fixes this problem. You could also make sure that everything is backwards compatible. So then it doesn't matter that a program who needs v1, uses v2.

  3. #3
    Join Date
    Nov 2003
    Posts
    1,902

  4. #4
    Join Date
    Apr 1999
    Posts
    3,585

    Re: Clash of DLL versions in co-existing Products

    From your description, I would fault your software vendor for not providing a versioned dll that is backward compatible. Aside from that, this sounds more like a packaging (install) issue. Is there any reason why the associated dll cannot be installed next to the product that needs it? In that way, you would not need to use an environment variable to control the search path.
    Gort...Klaatu, Barada Nikto!

  5. #5
    Join Date
    Jul 2008
    Posts
    42

    Re: Clash of DLL versions in co-existing Products

    dear seniors,

    thank you all for helping me out. after going through your explanation, going through the link provided in one of the reply, i did some kind of soul searching. i am tempted to explain it this way:

    1. Way back in the past Product 1 is packaged with about half a dozen (selective) DLLs of the vendor in its delivery.
    2. At present, Product 2 is packaged with same half a dozen updated DLLs in its delivery.
    2. Product 3 is (erroneously) packaged with two DLLs. these two DLLs are common to other two Products as well.

    3. i am presently getting issues with the release of Product 3 - a totally new product in my portfolio.

    4. in my PATH env, i noticed that the sequence of paths is - Product 1's bin, Product 2's bin, Product 3' bin. One could understand this easily because i have come up with Prodiuct 3 now, hence i just appended Product 3's bin (through the installation script) to PATH env variable.

    5. Leaving these two common DLLs, i have renamed other 4 DLLs of Product 1. Product 3 did not crash.
    6. i then removed Product 2's bin from PATH env value. Product 3's invocation gave me an error message saying that so and so DLL is not present. This DLL is one of those other 4 DLLs.
    7. this made me understand that, Product 3 also needs 6 DLLs of the vendor.
    8. When i renamed Product 1's DLLs, Product 3 is picking up remaining DLLs from the bin of Product 2. Since there is no version incompatibility between DLLs of Product 2 and Product 3, i did not get any crash.

    9. Effectively, i have packaged remaining 4 DLLs also into Product 3 and got relief.

    10. About compatibility of vendor's DLLs - mmmm....!

  6. #6
    Join Date
    Apr 1999
    Posts
    27,449

    Re: Clash of DLL versions in co-existing Products

    Why not do the easy thing, and that is place the DLL's in the same directory as the executable you're running? It sounds like you're doing a lot of work for nothing. If product 3 needs 6 DLL's, then just place those 6 DLL's in the product's executable folder. Then you don't need PATH statements being reset.

    I don't think this is a vendor's issue at all if the vendor has versioning info in their DLL (instead of just a time stamp on the DLL file). The vendor has no idea what is on the machine that your customers may be running. Maybe by chance, one of your customers uses the vendor's DLL's in an app you know nothing about. How do you solve that issue?

    Regards,

    Paul McKenzie
    Last edited by Paul McKenzie; September 10th, 2009 at 10:59 AM.

  7. #7
    Join Date
    Sep 2004
    Location
    Holland (land of the dope)
    Posts
    4,123

    Lightbulb Re: [RESOLVED] Clash of DLL versions in co-existing Products

    Why not do the easy thing, and that is place the DLL's in the same directory as the executable you're running?
    DoH! Forgot all about that option

  8. #8
    Join Date
    Jul 2008
    Posts
    42

    Re: [RESOLVED] Clash of DLL versions in co-existing Products

    Dear seniors,

    yes, i did the same thing all along - i.e put the DLLs that Product 3 needs in the same directory where Product 3's EXE is present.

    But, before posting the query, i wrongly understood that i need only two DLLs for Product 3. but this soul searching made me understand that, these two DLLs internally depend on the other four DLLs; and this is precisely the reason why Product 1 and Product 2 has 6 DLLs in their bin folder.

    after this (rather correct ) understnading of dependency of DLLs, i packaged all the required 6 dLLs into Product 3's bin as well, and went ahead with further steps.

    but one thing is sure - Product 1 has old DLLs. when Product 3 picked up the remaining DLLs from Product 1's bin, Product 3 gave a crash. i.e some version incompatibility.

  9. #9
    Join Date
    Apr 1999
    Posts
    27,449

    Re: [RESOLVED] Clash of DLL versions in co-existing Products

    Quote Originally Posted by gsmurthy30 View Post
    but one thing is sure - Product 1 has old DLLs. when Product 3 picked up the remaining DLLs from Product 1's bin, Product 3 gave a crash. i.e some version incompatibility.
    You cannot avoid this if you try and think too hard about what DLL's are installed, and then attempt to set path's and everything else you've mentioned.

    If your vendor has a popular library, there is a better than small chance that your customer has installed an app (not your app) that uses your vendor's DLL's. You have no idea what apps are on the customer's machine, let alone the version of the vendor's DLL's this app (that you know nothing about) uses.

    So the only way to resolve this issue is to package everything in the bin directory of your app. I would say that this is the only solution, and that is to package everything in one directory and be done with it.

    Regards,

    Paul McKenzie

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured