Unconfigured Ad Widget



No announcement yet.

IBM ADO.net data provider version compatibility

  • Filter
  • Time
  • Show
Clear All
new posts

  • IBM ADO.net data provider version compatibility

    Because my company is a software vendor, IBM's unfortunate habit of frequently changing the version number of their ADO.net data provider is creating big issues for us. I assume that there are other ISV's out there who write .Net applications for the IBM i, so I'm hoping someone has worked out a way to tackle this.

    To recap why this is creating issues for us:
    With each of the last three releases of the OS (V5R4, 6.1 and 7.1), the corresponding data provider version has changed. While I am not a .Net developer myself, what my .Net developers tell me (and this is supported by previous threads in this topic) is that when IBM changes the version number it breaks any .Net application with an ADO.net interface which wasn't built over that same version of the data provider. I grant that version induced breaking isn't unique to IBM's .Net components, and sometimes you really have to introduce changes that require a new version.

    But - while Microsoft's .Net framework itself allows you to have multiple versions of the same installed and applications built over different versions of that framework can coexist on the same PC as long as the version they need is installed, IBM i Access does not allow for concurrent installation of multiple versions. To test or develop with different versions, we have to uninstall and reinstall the whole shooting match. Another very annoying issue is that IBM will only ship you new versions when you're ordering hardware or updates so my developers don't have free access to the various versions of the software.

    What I am faced with is these choices:
    - dictate to the clients who use our software that they run a specific version of IBM i Access so that we only have to create a single version of our .Net software.
    - create and maintain multiple ADO.net version specific versions of all of my .Net software for the various versions of IBM i Access that we need to support.
    - figure out a way to create an intervening layer between our applications and the ADO.net data provider itself. Where programs need to use ADO.net functionality, they will interface with this component instead and then that component will determine which version of ADO.net is installed on the PC and translate the request into a version-appropriate interaction with the provider.
    - scrap using the ADO.net data provider completely figure out other ways to do what we use it for.

    I'm hoping that somewhere here I'm wrong (as in there really is a way to have concurrent installs of different versions of IBM i Access or IBM has some sort of backward compatibility solution). But short of that I think there are no choices which aren't ugly ones.