× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Thanks for that - we did get some direction from IBM about your proposal. This may be handy to know.

IBM says not to copy the data provider dll and include it with your install, because all you get is that one .NET dll, you don't get anything else that the .NET dll needs. So, if you have V7R1 installed on your target PC, for instance, and in V7R1 they changed a COM component that the .NET dll uses, you would still have a problem because the V5R4 version of the data provider that you send with your application would be looking for the V5R4 version of the COM component and wouldn't find it.

-----Original Message-----
From: systemidotnet-bounces@xxxxxxxxxxxx [mailto:systemidotnet-bounces@xxxxxxxxxxxx] On Behalf Of Walden H. Leverich
Sent: Wednesday, September 15, 2010 10:15 AM
To: .net use with the System i
Subject: Re: [SystemiDotNet] IBM ADO.net data provider version compatibility

Dave,

Tell your programmers not to use the GAC -- or more accurately not to use it for the client access reference. The GAC is cool in many way, and it allows you to have multiple versions of a single DLL in a common location on your machine. HOWEVER, to use a GAC dll you need to refer to it using its strong name, and the strong name includes the version number. Basically you're saying "I know I run against version 1.23, so always give me version 1.23, I don't care if there's also a version 1.24, or 2.1, etc."

What we've done successfully many times is to simply copy IBM ado.net assembly (IBM.Data.DB2.iSeries.dll) into the local /bin directory and reference that copy. You don't need the rest of client access in the bin directory (though you do need it installed). We've done this successfully across upgrades many times. The difference is, since we're using a local dll and not the GAC dll we don't need the strong name, we can simply refer to the dll by name and .net will use whatever version it finds.

Obviously if you develop against version 12 of the dll you may have problems running against version 10, but that's understandable. However, if you develop against version 10, then you should be ok running against version 12, or whatever 7.1 version # is.


-Walden

--
Walden H Leverich III
Tech Software &
BEC - IRBManager
(516) 627-3800 x3051
WaldenL@xxxxxxxxxxxxxxx
http://www.TechSoftInc.com
http://www.IRBManager.com

Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)


-----Original Message-----
From: systemidotnet-bounces@xxxxxxxxxxxx [mailto:systemidotnet-bounces@xxxxxxxxxxxx] On Behalf Of Dave Jorgensen
Sent: Tuesday, September 14, 2010 5:48 PM
To: SystemiDotNet@xxxxxxxxxxxx
Subject: [SystemiDotNet] IBM ADO.net data provider version compatibility

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.
--
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 thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.