|
Because my company is a software vendor, IBM's unfortunate habit of
frequently changing versions on 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. I have asked IBM, but still don't have a response.
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 what I found on relevant forum threads) 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 or
use virtualization. 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.
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. This really isn't an option for us - hopefully for
obvious reasons.
- 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. I'll pursue the final option before this one.
- 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. This is what we're most seriously considering - but I think
it simply shouldn't be necessary at all.
- 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.
It's difficult to understand why IBM would impose this sort of
limitation/difficulty - particularly when the hallmark of the IBM i has
always been that applications written for it dating back to its inception
have required next to no maintenance at all for reasons due to operating
system changes. Other than requiring our clients to stay within a couple
releases of us so we can compile to the lowest level of the OS that we
support and a few rare cases of avoiding specific PTF's/IBM i Access
versions, we've never had any need to dictate to them that they run any
specific release.
Help!
--
This is the .net use with the System i (SystemiDotNet) mailing list
To post a message email: SystemiDotNet@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/systemidotnet
or email: SystemiDotNet-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/systemidotnet.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
