When to use multiple projects in a solution?

[Dean Slindee]

I''m looking for some advice or experience from others before proceeding
with a very large VB.NET project. The project will be a suite of modules
(like accounts receiveable, payable, client master, appointment scheduling,
etc).

Each module will need to launch certain forms in the other module's
inventory of forms. It would be cleaner to assign each module to different
developer(s) as separate projects. But, because of the tight integration
needed, separate projects may limit the ability to launch forms from another
module. Am I correct in the last assumption, or not?

Any advice on how to architect this suite of modules?

Thanks,
Dean Slindee

[William Ryan eMVP]

Dean:

Dean Slindee" <sl*****@mindspring.com> wrote in message
news:eo**************@TK2MSFTNGP09.phx.gbl...

I''m looking for some advice or experience from others before proceeding
with a very large VB.NET project. The project will be a suite of modules
(like accounts receiveable, payable, client master, appointment scheduling, etc).

Each module will need to launch certain forms in the other module's
inventory of forms. It would be cleaner to assign each module to different developer(s) as separate projects. But, because of the tight integration
needed, separate projects may limit the ability to launch forms from another module. Am I correct in the last assumption, or not?

Any advice on how to architect this suite of modules?

Thanks,
Dean Slindee


What is the alternative you are comparing against? In general, I think this
is a pretty common situation and breaking it into modules is defintiely a
more maintainable way to do it and as long as everyone distributes the
newest changes frequently (or checks things back into Source Control
Regularly), you shouldn't have a problem. Either way though you'd need to
have people distribute and update things frequently whether you had one
project in a solutino or 500.

One word of advice though...if you are going to have a bunch of people
working on different modules, make SURE that they complete and check in
their unit tests regularly and due smoke-test builds regularly. You don't
want to get moving thinking things work, only to find that there was a bug
that needs changed and fixing it is going to break a bunch of other logic.
And in my experience, if you don't use Unit Tests or you let them get old,
you won't be able to do this correctly because it will be moved to the back
burner. That's when things start getting really stressful.

[Paul Hatcher]

Dean

Your best bet it to create all forms via a central mechanism otherwise you
are going to have a lot of dependencies that will be nasty to manage
long-term.

A solution I designed puts the information about which assembly a form is
into the database, this can be mantained via a design-tool if someone moves
a form between assemblies etc. Then, in the code you use a formcode to
request the relevant form and the form is created via reflection.

Once feature I like is that in complex apps yo sometimes need a different
form depending on the role of the person performing the task - this removes
the security problem from the caller and centralises it.

Paul

"Dean Slindee" <sl*****@mindspring.com> wrote in message
news:eo**************@TK2MSFTNGP09.phx.gbl...

I''m looking for some advice or experience from others before proceeding
with a very large VB.NET project. The project will be a suite of modules
(like accounts receiveable, payable, client master, appointment scheduling, etc).

Each module will need to launch certain forms in the other module's
inventory of forms. It would be cleaner to assign each module to different developer(s) as separate projects. But, because of the tight integration
needed, separate projects may limit the ability to launch forms from another module. Am I correct in the last assumption, or not?

Any advice on how to architect this suite of modules?

Thanks,
Dean Slindee