Project Folder Structure

I've been creating Excel reports for a few years, but
have now inherited a server with a bunch of VB 6.0
projects. It's a real mess. Files are strewn about all
over the place with no real regard as to what goes where.
Modules are FULL of sloppy code and tons of commented old
code.

I'm going to take on the task of deleting projects they
don't need and cleaning up the ones they do need. I know
the language fairly well from using VBA, but am not too
aware of the best way to structure the files associated
with each project. Most of the projects that I'm keeping
use the same modules. I'm thinking of putting those
modules in one folder for each project to reference.
Also, the standard executables from these projects are
used in Scheduled Tasks. I'm thinking I could put all of
the EXEs in one subfolder. Then create separate folders
for each VBP and related files. Does this sound about
right?

Does someone know of a book that is not so much about how
to write code, but best practices on managing VB projects?

tod

"Tod" <todtown@swbell.net> wrote in message
news:1fe601c4bdbf$f05a9d10$a601280a@phx.gbl...
> I've been creating Excel reports for a few years, but
> have now inherited a server with a bunch of VB 6.0
> projects. It's a real mess. Files are strewn about all
> over the place with no real regard as to what goes where.
> Modules are FULL of sloppy code and tons of commented old
> code.
>
> I'm going to take on the task of deleting projects they
> don't need and cleaning up the ones they do need. I know
> the language fairly well from using VBA, but am not too
> aware of the best way to structure the files associated
> with each project. Most of the projects that I'm keeping
> use the same modules. I'm thinking of putting those
> modules in one folder for each project to reference.
> Also, the standard executables from these projects are
> used in Scheduled Tasks. I'm thinking I could put all of
> the EXEs in one subfolder. Then create separate folders
> for each VBP and related files. Does this sound about
> right?
>
> Does someone know of a book that is not so much about how
> to write code, but best practices on managing VB projects?
>
> tod

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

"Tod" <todtown@swbell.net> wrote in message =
news:1fe601c4bdbf$f05a9d10$a601280a@phx.gbl...
> I've been creating Excel reports for a few years, but=20
> have now inherited a server with a bunch of VB 6.0=20
> projects. It's a real mess. Files are strewn about all=20
> over the place with no real regard as to what goes where.=20
> Modules are FULL of sloppy code and tons of commented old=20
> code.=20
>=20
> I'm going to take on the task of deleting projects they=20
> don't need and cleaning up the ones they do need. I know=20
> the language fairly well from using VBA, but am not too=20
> aware of the best way to structure the files associated=20
> with each project. Most of the projects that I'm keeping=20
> use the same modules. I'm thinking of putting those=20
> modules in one folder for each project to reference.=20
> Also, the standard executables from these projects are=20
> used in Scheduled Tasks. I'm thinking I could put all of=20
> the EXEs in one subfolder. Then create separate folders=20
> for each VBP and related files. Does this sound about=20
> right?=20
>=20
> Does someone know of a book that is not so much about how=20
> to write code, but best practices on managing VB projects?
>=20
> tod

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.

--


Randy Birch
MS MVP Visual Basic
http://vbnet.mvps.org/


"Tod" <todtown@swbell.net> wrote in message
news:1fe601c4bdbf$f05a9d10$a601280a@phx.gbl...
: I've been creating Excel reports for a few years, but
: have now inherited a server with a bunch of VB 6.0
: projects. It's a real mess. Files are strewn about all
: over the place with no real regard as to what goes where.
: Modules are FULL of sloppy code and tons of commented old
: code.
:
: I'm going to take on the task of deleting projects they
: don't need and cleaning up the ones they do need. I know
: the language fairly well from using VBA, but am not too
: aware of the best way to structure the files associated
: with each project. Most of the projects that I'm keeping
: use the same modules. I'm thinking of putting those
: modules in one folder for each project to reference.
: Also, the standard executables from these projects are
: used in Scheduled Tasks. I'm thinking I could put all of
: the EXEs in one subfolder. Then create separate folders
: for each VBP and related files. Does this sound about
: right?
:
: Does someone know of a book that is not so much about how
: to write code, but best practices on managing VB projects?
:
: tod

On Fri, 29 Oct 2004 07:02:34 -0700, "Tod" <todtown@swbell.net> wrote:

>I've been creating Excel reports for a few years, but
>have now inherited a server with a bunch of VB 6.0
>projects. It's a real mess. Files are strewn about all
>over the place with no real regard as to what goes where.
>Modules are FULL of sloppy code and tons of commented old
>code.
>
>I'm going to take on the task of deleting projects they
>don't need and cleaning up the ones they do need. I know
>the language fairly well from using VBA, but am not too
>aware of the best way to structure the files associated
>with each project. Most of the projects that I'm keeping
>use the same modules. I'm thinking of putting those
>modules in one folder for each project to reference.
>Also, the standard executables from these projects are
>used in Scheduled Tasks. I'm thinking I could put all of
>the EXEs in one subfolder. Then create separate folders
>for each VBP and related files. Does this sound about
>right?

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.