Single or multiple assemblies in big apps?

[Guest]

Hi everyone,

I have a question about .NET code sharing and reuse, and also about
application design best practices / guidelines.

Currently, we have many different .NET projects in source depot. Although
they are different, in some of them we share C# code by referencing source
files that are external (not part of the projects) on each project.

For instance, some of our projects have the typical “sources†file with:

SOURCES = \
..\..\some_other_different_unrelated_project_A\fileA1.cs \
..\..\some_other_different_unrelated_project_B\fileB1.cs \
..\..\some_other_different_unrelated_project_B\fileB2.cs \
Program.cs
Class.cs

And so on.

Some people in my team think that DLLs and assemblies are evil and should be
completely avoided. Therefore, they advocate treating all projects in the
depot as one huge, monolithic project (even they are not, as they are
different projects), sharing code by referencing source files all over the
depot.

Basically, each application has one and only one assembly containing all the
application source code plus all source code that belong to other projects
too but is reused by referencing the other project(s) C# source files.

Other team members (BTW facing huge opposition) insist in packing the
shareable code into one or more assemblies, although for some people,
assemblies and DLLs are absolutely forbidden.

Can someone please tell me the pros and cons of each approach? Is it right
to be completely against packing certain substantial modules or pieces of
functionality into separated assembly/assemblies, as opposed to having one
and only one single, huge monolithic assembly containing the whole
application + other project source files?

Those in favor of having shareable code packed into separate assemblies,
instead of putting everything (all the source code of the application plus
the sources of our libraries, plus the sources of all subsystems, etc.) into
one, big monolithic assembly, point to these other URIs:

http://msdn.microsoft.com/practices/compcat/default.aspx?pull=/library/en-us/dnbda/html/distapp.asp

http://msdn.microsoft.com/practices...pull=/library/en-us/dnbda/html/apparchch2.asp

http://weblogs.asp.net/savanness/archive/2003/07/22/10417.aspx

http://msdn.microsoft.com/library/d...n-us/cpguide/html/cpconassembliesoverview.asp

So, I wonder, are there any guidelines and/or best
practices/patterns/anti-patterns in regards to C# source code sharing and
reusing among different projects? Any authoritative answers? Is it
reassonable to build big, different applications from one huge source tree,
having only one and just one assembly per application and nothing more? Or it
makes more sense to split the app into multiple assemblies, but keeping the
number of assemblies to a minimum?

Thanks and regards,

Claudio

 

[Guest]

Claudio

I am an advocate of building assemblies, since this is after all what code
re-use is about.

For example my company has certain portions of functionality common accross
the entire suite, so we have elected to build strong named assemblies around
this commonality who are then installed into the GAC.

Also, if commonality is packaged in a single place (i.e. an assembly) and
this single place is named accordingly (eg. myCompany.myMeaningfulName), then
you don't have to go sifting through all of your source code to find that bit
of code that you know someone wrote last year.

..net makes (managed ie. written using .net) dlls much easier to manage
through the Global assembly cache, through assembly versioning, and through
private and shared assemblies.

There are many good articles on the web (including here) about version
management in .net and these articles include good explanations of how it is
handled.

I'm no expert, but the object oriented community's view on code re-use is
focused on OBJECT reuse rather than physical code file re-use.

As for building applications as one huge assembly ... well, that doesn't
make it very easy to apply bug fixes and enhancements to your product without
a complete re-compile ... I'm sure that your release manager would be
delighted to hear that by simply pre-preparing a bunch of assemblies you can
save hours (over the year) in wasted build time.

Further I'm sure your development manager would also be delighted to see how
easy splitting your monolithic application into seperate assemblies will make
it easier for developers to work on different areas of the product without
detriment to the productivity of other team members working on the same
product.

Developing areas of functionality in isolation means that when you write
your code (and your unit tests) you can be certain that by the time you hand
it over to the build engineer if there is a problem, it's is not going to be
with your code.

It's easy to write and maintain unit test for a small code project than it
is for a monolithic 160000 file project.

I hope that makes sense, and I also hope that everyone else agrees with me )

 

[Dinsdale]

First off this is JUST my opinion:

1) I think the GAC is evil and should be avioded. We are moving away
from a central repository to self describing files for a reason:
Because COM sucked the life out of developers. Besides, what is the
problem with having 3 copies of a 500kb dll when your hard disk is 250
GB?

2) I have been able to cut bugs down to almost nothing by using proper
unit testing of separate assemblies - Define what your inputs and
outputs are and then code your assemblies accordingly. Ensure your
interfaces are descriptive, flexible and STABLE. When everything in the
sub assemblies (Dlls) is complete and tested, include references to
COMPILED assemblies, not projects. That way you can ensure that your
app works correctly agains myDLL.dll version 1.xx.xxxx and someone else
on the team isn't going to break that by tweaking something. Once the
dll is stable, then it can be released and re-used.

3) I have SAVED MY ASS by having business logic classes separate from
UI and DAL. Imagine this: Engineer goes to China for project and bug is
found in my code. I've already moved on in my development from the
release version so I can't fix it in the current version. I find out
the problem is in a class library that has changed signifigantly so I
get an old version from source control, hook it up to my test harness
(i.e. winform with three buttons named button 1,2,3) fix bug, test,
email a 300k file to the engineer that simply copy/replaces the file in
question. I look like a hero and it was my stupid mistake in the first
place

4) Everything that bill said.

Cheers
Dinsdale

 

[Guest]

Hi Bill and Dinsdale

Thanks for your kind responses. These should help my team improve the way we
design and develop some of our applications. Thanks so much.

Claudio