Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Gerhard Fiedler wrote: > IMO one either makes sure that the DLL interface stays the same -- or lets > programs use the DLL of the version that they need. You said that the > problem is that sometimes Windows decides that a DLL with a different path > but same name that is already in memory can be used instead of the one with > the exact path requested. Well... so change the name if you change the DLL > interface, and everything is well. If the interface of protocol.dll build > 2230 is not compatible with the interface of protocol.dll build 2151, then That's a lot harder than it sounds - there's no support for anything like that in visual studio so you'd have to rebuild the project files for each release (which is a bit of a chicken and egg situation even if you scripted it). You can't just rename a DLL - it stores its 'real' name internally and uses that. We already do that on the Unix builds but of course the build system is designed to work that way. On Windows we'd have to write it from scratch. Once we get to VS2005 the Manifests contain the checksums of the libraries that the programs use - which is *supposed* to fix DLL Hell once and for all (it remains to be seen if it does this time...). Until that time we have to use suboptimal solutions. Tony