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.
Tony Hoyle wrote: > Flávio Etrusco wrote: >> I didn't follow the discussion _much_ closely, so forgive if I'm BSing, >> but IMHO the question is: why does the cvsnt running as _client_ need >> to to follow the registry setting instead of just using the local DLLs? > > CVSNT isn't the only user of cvsapi - there are currently at least 5 of > them and they can't all be put in the same directories. > > There is no requirement for the DLLs loaded by it to be local to > anything. The problem with this approach that I recently encountered is as follows. TortoiseCVS needs a defined version of the client, since it sends commands to it and parses the output. Both change between versions (sometimes more, sometimes less), so I guess it's reasonable that TortoiseCVS expects a certain version of cvs.exe to interact with. To make sure that it uses the correct version, it installs that version. That used to work fine, at least here and up to now. But I have also a command line cvsnt installation in a different directory on my system. I didn't specifically install that as a server and it doesn't run as a server -- I just ran the installer, unselected the protocols I'm not interested in, and that's it. This installation still works fine (build 2151). So when I installed the latest version of TCVS, it installed cvsnt build 2230 in its directory. And boom... cvs.exe 2230 did not work with the DLLs provided by 2151. I only could make it work by using the cvs.exe.local file. (The simcvs.exe approach suffers from the drawback that TCVS would then run with an arbitrary version of cvs.exe -- which probably would only be acceptable if the interface details of cvs.exe didn't change between versions. Which of course they do, in unpredictable ways, as there is no formal interface spec.) 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 how about naming protocol.dll build 2230 protocol-build2230.dll and protocol.dll build 2151 protocol-build2151.dll? After all, naming both protocol.dll gives the (wrong) impression that they are interchangeable and present the same API. Which apparently they don't -- or else cvs.exe build 2230 wouldn't have a problem with protocol.dll build 2151. This would make pretty much everybody happy; nothing gets broken, every client gets the DLLs it needs, and DLLs with the same name are actually interchangeable. Gerhard