The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

City Desk and VB DLLs

I noticed when I installed City Desk that the VB and support DLLs were all located in the installation directory instead of the Windows/System folder.  It is my assumption that this was done to make sure the program uses the same versions that it was developed and tested with.

Is there any other reason this was done?  And how important is this?  I am developing an app (currently being beta tested) that copies the files of the Windows/System folder.  Should I be rethinking this?
Nick Koranda Send private email
Monday, June 27, 2005
 
 
Well, Nick, as long as you are CERTAIN that you are not copying older DLL's over newer DLL's, and are CERTAIN that the newer DLL's have ALL the functionality you have been using in the older DLL's, then sure, copy into the system directory all you like.

Now, once you deliver there MAY be newer DLL's, so your code will have to run with the newer DLL's.  How confident are you that the newer DLL's will support your code?

And on what do you base that confidence?  And are you prepared to test with any and all new DLL's that come out, on the off chance that one of them may break your code?

And when you un-install, are you CERTAIN that you are not removing any DLL essential to the operation of OTHER code?

Leaving your DLL's in the execution subdirectory gets around all these issues.  You don't care what DLL's get upgraded, you have a fixed target to work with.  Uninstalling is easy -- nobody else should be using your DLL's, and you're not stepping on any DLL's that anybody else may be using.

The price for this is additional disk space storage for your DLL's.  And with the price of disk space these days, that doesn't seem to be a major cost, compared to all the testing, verification, and risk you would take when doing the other approach.

Oh, and did I mention support calls because somebody installed a newer DLL in the system directory over YOUR DLL, which causes YOUR application to break?  And how do you even determine that happened, or when it happened, or WHICH DLL got upgraded?
AllanL5
Monday, June 27, 2005
 
 
Short answer: "It is my assumption that this was done to make sure the program uses the same versions that it was developed and tested with."

Well yes, possibly, but that's a HUGE plus value and risk reduction compared to putting them in the System directory.
AllanL5
Monday, June 27, 2005
 
 
If you're doing your project in VB6, you'll need to use the "LOCAL File Method". That's where you have a dummy file with yourprojectname.exe.local in the same directory. Works on 98, and 2000 and above. The .local file tells the vb runtime to look in the local directory.
Steve Sutton Send private email
Monday, June 27, 2005
 
 
" support calls because somebody installed a newer DLL in the system directory over YOUR DLL, which causes YOUR application to break?  "

And don't forget: when someone, in error, installs an OLDER version of the DLL over your version in the \systemn directory.
Mr. Analogy (uISV) Send private email
Wednesday, June 29, 2005
 
 
Thanks for the information.  I have switched my setup script to copy the files to the app directoy.  I believe this will be a better approach as well.
Nick Koranda Send private email
Wednesday, June 29, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz