473,222 Members | 1,745 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,222 software developers and data experts.

Single or multiple assemblies in big apps?

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\fil eA1.cs \
..\..\some_other_different_unrelated_project_B\fil eB1.cs \
..\..\some_other_different_unrelated_project_B\fil eB2.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/...ml/distapp.asp

http://msdn.microsoft.com/practices/...apparchch2.asp

http://weblogs.asp.net/savanness/arc.../22/10417.aspx

http://msdn.microsoft.com/library/de...esoverview.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

Jul 28 '06 #1
3 2026
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 :o)

--
Of all words of tongue and pen, the saddest are: "It might have been"

Bill.Richards @ greyskin .co .uk
http://greyskin.co.uk
"Claudio Pacciarini" wrote:
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\fil eA1.cs \
..\..\some_other_different_unrelated_project_B\fil eB1.cs \
..\..\some_other_different_unrelated_project_B\fil eB2.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/...ml/distapp.asp

http://msdn.microsoft.com/practices/...apparchch2.asp

http://weblogs.asp.net/savanness/arc.../22/10417.aspx

http://msdn.microsoft.com/library/de...esoverview.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
Jul 28 '06 #2
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

billr wrote:
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 :o)

--
Of all words of tongue and pen, the saddest are: "It might have been"

Bill.Richards @ greyskin .co .uk
http://greyskin.co.uk
"Claudio Pacciarini" wrote:
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\fil eA1.cs \
..\..\some_other_different_unrelated_project_B\fil eB1.cs \
..\..\some_other_different_unrelated_project_B\fil eB2.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/...ml/distapp.asp

http://msdn.microsoft.com/practices/...apparchch2.asp

http://weblogs.asp.net/savanness/arc.../22/10417.aspx

http://msdn.microsoft.com/library/de...esoverview.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
Jul 28 '06 #3
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
--

Claudio Pacciarini

"Claudio Pacciarini" wrote:
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\fil eA1.cs \
..\..\some_other_different_unrelated_project_B\fil eB1.cs \
..\..\some_other_different_unrelated_project_B\fil eB2.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/...ml/distapp.asp

http://msdn.microsoft.com/practices/...apparchch2.asp

http://weblogs.asp.net/savanness/arc.../22/10417.aspx

http://msdn.microsoft.com/library/de...esoverview.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
Jul 31 '06 #4

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

3
by: AARON PECORARO | last post by:
I need to split apart my web application into multiple projects to allow it to be distributed in parts, but all of the projects need to work together (ie. they need to share session information)....
6
by: Tom Dacon | last post by:
If you're not putting assemblies in the GAC, but are referencing shared code with copylocal=true into the projects that use them, is there any value to signing the assemblies? In the environment...
1
by: loretta.stokes | last post by:
I manage our nightly builds for all of our products. Since we have added our .NET assemblies to our nightly build, it has been a learning process. I have come across a couple of situations that I...
5
by: Edward Mitchell | last post by:
I am trying to include two class files into a web service project. The structure I have is a top level solution and project in a folder and below that, the web service project in it's own folder. ...
3
by: Shikari Shambu | last post by:
Hi All, I have a situation where multiple applications are sharing some pages/ controls. So, I have a separate common project that has the common pages/ controls. My question is how do I...
4
by: Jeff | last post by:
We have multiple ASP.Net web apps in development. As a standard we are looking to go with SQL Server to hold state information. Can we have the multiple apps all point to a single State DB? Or...
1
by: EricMatz | last post by:
I work for a medium-sized insurance company, developing web-based systems for our independent agents. There are four primary applications we provide - one that serves as an agent portal (ASP), and...
5
by: Peter Rilling | last post by:
Okay, the other day I was talking with someone about assemblies. He said something that I am not really sure about. He said that a DLL or EXE can contain more then one assembly (although the IDE...
1
by: David Herbst | last post by:
I have a solution that contains one main web project, ten sub web projects and a controls library project all in a single web application. I followed the steps in the following MS KB: How To...
0
by: VivesProcSPL | last post by:
Obviously, one of the original purposes of SQL is to make data query processing easy. The language uses many English-like terms and syntax in an effort to make it easy to learn, particularly for...
3
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 3 Jan 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). For other local times, please check World Time Buddy In...
0
by: mar23 | last post by:
Here's the situation. I have a form called frmDiceInventory with subform called subfrmDice. The subform's control source is linked to a query called qryDiceInventory. I've been trying to pick up the...
0
by: abbasky | last post by:
### Vandf component communication method one: data sharing ​ Vandf components can achieve data exchange through data sharing, state sharing, events, and other methods. Vandf's data exchange method...
2
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 7 Feb 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:30 (7.30PM). In this month's session, the creator of the excellent VBE...
0
by: fareedcanada | last post by:
Hello I am trying to split number on their count. suppose i have 121314151617 (12cnt) then number should be split like 12,13,14,15,16,17 and if 11314151617 (11cnt) then should be split like...
0
by: stefan129 | last post by:
Hey forum members, I'm exploring options for SSL certificates for multiple domains. Has anyone had experience with multi-domain SSL certificates? Any recommendations on reliable providers or specific...
0
Git
by: egorbl4 | last post by:
Скачал я git, хотел начать настройку, а там вылезло вот это Что это? Что мне с этим делать? ...
0
by: MeoLessi9 | last post by:
I have VirtualBox installed on Windows 11 and now I would like to install Kali on a virtual machine. However, on the official website, I see two options: "Installer images" and "Virtual machines"....

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.