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" <[e-mail]> wrote in message
news:%2********************@tk2msftngp13.phx.gbl.. .

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

[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]" <ni*******@hotmail.nospam.com> wrote in message
news:4q********************@comcast.com...

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" <[e-mail]> wrote in message
news:%2********************@tk2msftngp13.phx.gbl.. .

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]]

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" <[e-mail]> wrote in message
news:OR****************@TK2MSFTNGP14.phx.gbl...

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]" <ni*******@hotmail.nospam.com> wrote in message
news:4q********************@comcast.com...

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" <[e-mail]> wrote in message
news:%2********************@tk2msftngp13.phx.gbl.. .

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

[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]" <ni*******@hotmail.nospam.com> wrote in message
news:2J********************@comcast.com...

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" <[e-mail]> wrote in message
news:OR****************@TK2MSFTNGP14.phx.gbl...

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]" <ni*******@hotmail.nospam.com> wrote in message
news:4q********************@comcast.com...

> 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" <[e-mail]> wrote in message
> news:%2********************@tk2msftngp13.phx.gbl.. .
>> 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
>>
>>
>
>