VB Forum / General / October 2004

Not aware of any books. There is the occasional blog and article, but
unfortunately there are as many 'Best Practices' when it comes to structure
as there are programmers. <g>

First thing I would do (after a raw backup of everything). Is to re-open
each project that produces a deliverable. Copy everything that is needed
into the project folder. (I would not be too concerned with 'shared' files
at this point, because if it is in that big of mess - I wouldn't be
surprised if some of the 'shares' aren't.) Make sure the project compiles
with binary compatibility(reproduces production) then save it into VSS.
After your have a clean/correct compile for each project. Then blow away
everything else.

Then, and only then, would I attempt to organize or rearrange the overall
development environment. If you attempt to shuffle stuff around beforehand
you will likely quickly lose sanity.

hth
-ralph

Here's a VBScript I use to archive VBP projects.
You will need an up-to-date installation of WSH/VBScript, found
in IE6, and the zip utility PKZip 2.50 (cmdline).

http://mysite.verizon.net/res1ur2j/ZipVBP.zip

The above VBS will parse the project VBP file, write a
pkzip central directory (with full paths), then launch the
zip utility. All supporting modules, classes, and forms are
zipped up. You can remedy the disparate paths when extracting
out the project -- turn off use folder names.

I use pk250c32.exe from PKWare for commmandline zip.

hth,
tlviewer (VS6 sp4, Win2k sp4, P4 2.0 GHz 512 RAM, Office2k sp3)

You may want to grab and install mztools (www.mztools.com), as it provides a
function to identify variables and procedures declared in the project that
are unused. Working with a backup of the project, I'd run mztools against it
and comment out all the items identified as unused. Then if the program runs
as expected, delete all the commented-out code and start working with what's
left.

I strongly recommend that you back up thoroughly first.

Each project has a .VBP file which contains the file names of all
modules used in the project.
Annoyingly these can be very 'relative' eg: ..\..\dir1\module.bas

If you are dealing with a really messy programmer then there could be
multiple modules with the same names but very slightly different code.
There could also be 'cross-links' all over the disk.

If the EXEs belong in the same suite, then, yes they should be in the
same directory, but I expect there will be more than one suite of Apps
on the machine.

My preferred setup is:

x:\dev\uslib     ' modules used by /everything/
x:\dev\app1    ' standalone App source & exe
x:\dev\app2
x:\dev\suite1   ' exes for the suite in here
x:\dev\suite1\common   ' modules common to suite1
x:\dev\suite1\appA
x:\dev\suite1\appB
x:\dev\suite1\appC

If you have large Apps - or rather Apps with many modules, then it
could be an idea to programmatically move them around
- or hunt for a utility to do that for you

Manually moving Apps from within VB is time consuming, easy to screw
up and thoroughly unpleasant as 'real' file names and paths are
inconveniently obscured from the programmer.

Personally I would programatically collect and analyse the .VBP files
before doing anything else.

Also watch out for things like .FRX files and possibly resource files.