Bruen, Bruce
Bruce.Bruen at railcorp.nsw.gov.au
Mon Dec 12 16:17:41 CST 2005
>> That may be true, but from the previous email, it was my assumption that you can not run 1.1 on 2.0 Most emphatically yes. By which I mean no you can't. The runtime checks any reference down to the 3rd part of the assembly version that is referenced. So if your app was ditributed against, say, system.dll v1.1.1234.348734 and your client has 1.1.16789.2343 installed it will run OK. IOW M$ has released an UPDATE to the 1.1 runtime. It will be backward compatible with all 1.1 versions. However it is NOT compatible with any version from 1.0.x.y nor 2.0.x.y Your client can have both 1.1 and 2.0 of the framework (read runtime) installed side-by-side on their machine (or even all three like me). The only cost is disk space. This means that YourApp using .NET OLEdb 1.1 components will not be clobbered when our client installs MyApp which uses .NET OLEdb 2.0 components... And they are pretty different I can tell you! M$ included [u]some[/u] backward compatibility in 2.0 but its at the developer end not the runtime end. For example, the "new" menu component MenuStrip replaces the MainMenu component of 1.1 System.Windows.Forms but they have also included a version of MainMenu in 2.0 so if you, the developer so choose you can still use the old component. But there are no guarantees that MainMenu will exist in 3.0 or even 2.1 SDKs. Nice eh? The idea is that new version components will not clobber apps that are designed for a prior framework. Consider the debacle of trying to run an A97 app on A23K! Half the libraries are changed. Nothing works as it did and your only option is to update YourAccessApp(A97) if our client decides to use MyAccessApp(A23K) as well - not our client's problem, not my problem - I got paid for MyAccessApp. But it's YOUR problem and our client is going to tell you so. Note, though that this applies AFAIDWK to assemblies installed in the GAC. Any component assemblies that are installed in the ThatApp directory are associated with ThatApp only. What this means is that if I distribute a dll called say DataBaseAdvisors.dll that installs in the ?/MyApp/bin directory and you distribute a dll with the same name in ?/YourApp/bin they will never collide. You can also "sign" assemblies, strong name them and then install them in the GAC. I haven't looked into this yet. Is this M$ getting away from backward compatibility deliberate? Yes. See Shamil's posts on Joel's articles. M$ DON'T WANT TO support bcakward compatibility in the new world, its too expensive. But rather than foist the responsibility onto the developer they have come up with this approach. Its not too bad. Developer's don't have to worry about the mine-clobbered-yours-haha problem outlined above, at a cost of client node disk space. There is actually nothing new in this, its just that non-guaranteed compatibility has moved up from the OS space to the end-user application space. And with the plethora of dll's that are killing apps left right and centre at the moment I reckon it's a good idea. bruce -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Josh McFarlane Sent: Saturday, 10 December 2005 6:54 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] OT: Is My ASP Covered On 12/8/05, Michael Maddison <michael at ddisolutions.com.au> wrote: > I believe the idea is that you deploy against the version you build > with. > If MS release a new version it cant break something in a previous > version. > New versions get added and hopefully don't break existing code, chews > up a bit of disc space but who cares? > No more dll hell. If that's true it works for me. > We shall see... That may be true, but from the previous email, it was my assumption that you can not run 1.1 on 2.0 In this case, major versions are not backwards compatible, in which case, do you not still have an issue of DLL hell? (Got that app that needs both 1.1 and 2.032.123RC2? Best hope they don't conflict at all!) -- Josh McFarlane "Peace cannot be kept by force. It can only be achieved by understanding." -Albert Einstein -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com This e-mail and any attachments may contain confidential information that is intended solely for the use of the intended recipient and may be subject to copyright. If you receive this e-mail in error, please notify the sender immediately and delete the e-mail and its attachments from your system. You must not disclose, copy or use any part of this e-mail if you are not the intended recipient. Any opinion expressed in this e-mail and any attachments is not an opinion of RailCorp unless stated or apparent from its content. RailCorp is not responsible for any unauthorised alterations to this e-mail or any attachments. RailCorp will not incur any liability resulting directly or indirectly as a result of the recipient accessing any of the attached files that may contain a virus.