Large solution

[Tim Marsden]

HI,

I am developing a application in vb.net. I split down my functionality
into several separate DLL's. The solution is becoming very large, nearly 100
projects, each project a dll's. There is one entry exe.

It is very slow to load and compile now. All my references are project
references, is there a standard way to split the solution. In the past I
have had versioning problems if a compile groups of projects individually.

Tim

 

[Nick Malik [Microsoft]]

100 projects?

Surely you aren't actually _working_ on 100 projects at a time?

I would suggest you get NAnt (http://nant.sourceforge.net/) and set it up to
perform your recompilations for you.
Then when you are actually working in the code, use a solution file that
contains a small set of related projects, so that load time is reasonable.

NAnt is a build tool. Let it do your compiles for you.

I'm not going to criticize your structure, because I don't know what you are
trying to accomplish. However, I would also suggest that you want to create
assemblies according to the principle of cohesion. That is, you group
together classes that logically tie together in the same layer, so that you
can (a) allocate the work, (b) seperate the concerns, and (c) make it easy
to find and change business rules. Even in very large systems, it is
unusual to have 100 projects. That said, check out NAnt.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.

 

[Tim Marsden]

Thanks for the reply.

Please advise, is it better to have several dll's each with a small amount
of function or a bigger dll with more.
Does this effect the load time of objects at runtime if they are part of a
large dll.

Thanks
Tim

 

[Nick Malik [Microsoft]]

The load time of objects at runtime is slightly improved if they are part of
a larger DLL, because the cost to load the dll is performed once for every
object in it, often very close to when the application first starts up.
However, for the vast majority of applications, load time is not the issue.
Humans can't percieve the distinction.

The biggest costs associated with your application will be associated with
the cost of maintaining it. The less expensive it is to maintain, the
better.
That is why so many folks try to "guess" what is needed in the future and
put in bits of code to support those future needs. Some things are useful
(like using the configuration file for all of your deployment settings and
web service locations). Others are dubious at best, but it is definitely a
driving force in software development.

With all due respect, I would personally find it difficult to maintain an
application with 100 assemblies.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.

 

[Tim Marsden]

Many Thanks

I will rethink the solution. Is it better to use project references, or
reference the built assembly. When using assembly references I get into
trouble with version numbers etc.

Regards Tim

 

[Nick Malik [Microsoft]]

Hi Tim,

Is it better to use project references, or
reference the built assembly. When using assembly references I get into
trouble with version numbers etc.

Like I said, use NAnt to recompile everything when it is time to make a new
version. That would give you more control when you are in an environment
with a large number of projects. With less than a dozen projects, this
isn't a problem and in that case, I'd recommend using project references.
Otherwise, reference the assembly.

One common thing that sometimes bites folks is this: when you make a
reference, always reference the contents of the /bin folder of the
referenced assembly, not the /obj folder.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.