Re: Single assembly or multiple assemblies for big apps?

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

It's really not all that difficult of a decision. If the code can be
re-used or is likely to be updated in the future, put it into its own
assembly. Those that would tell you otherwise need to put down their
abacuses and get with the "program".

Really, the only argument that I could understand against multiple
assemblies is that versioning and dependencies become issues. But, if you
take just a little time to learn about these things, you'll find that they
aren't nearly as evil as they once were (pre-.NET).

I'd like to hear one of them try to sell a manager on the additional
time/money that will be required when code needs to be duplicated or when a
huge application must be re-deployed because of a few code changes.

Honestly, print this message out and leave it on the desks of all those who
want to write the one, huge application. They may be a majority voice where
you work, but they are a miniority voice in the client/server development
world.


"Claudio Pacciarini" <ClaudioPacciarini@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message news:7D7F2970-1951-41B2-8BB3-40DACBD882B8@xxxxxxxxxxxxxxxx
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/compcat/default.aspx?pull=/library/en-us/dnbda/html/apparchch2.asp

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

http://msdn.microsoft.com/library/default.asp?url=/library/en-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



.

Relevant Pages

  • Re: Single or multiple assemblies for big apps and code reuse?
    ... I have a question about .NET code sharing and reuse, ... Some people in my team think that DLLs and assemblies are evil and should ... sharing code by referencing source files all over the ... When one application requires a change to a shared source file, ...
    (microsoft.public.dotnet.framework)
  • RE: Single or multiple assemblies for big apps and code reuse?
    ... design and develop some of our applications, ... application design best practices / guidelines. ... Some people in my team think that DLLs and assemblies are evil and should be ... sharing code by referencing source files all over the ...
    (microsoft.public.dotnet.framework)
  • Re: Single assembly or multiple assemblies for big apps?
    ... way we design and develop some of our applications. ... Some people in my team think that DLLs and assemblies are evil and should ... sharing code by referencing source files all over ...
    (microsoft.public.dotnet.framework.performance)
  • RE: Single assembly or multiple assemblies for big apps?
    ... way we design and develop some of our applications. ... Some people in my team think that DLLs and assemblies are evil and should be ... sharing code by referencing source files all over the ...
    (microsoft.public.dotnet.framework.performance)
  • Re: How to have multiple language sources in one project?
    ... > language and then I can't add a source of a different language to it. ... A single compiler will only compile code in a single language (the exception ... compiler for all source files - thus projects can only be used to compile ... Microsoft assemblies are multimodule. ...
    (microsoft.public.dotnet.general)