| Groups | Blog | Home |
dotnet performance : Single assembly or multiple assemblies for 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\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
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@discussions.microsoft.com> wrote in message news:7D7F2970-1951-41B2-8BB3-40DACBD882B8@microsoft.com... [quoted text, click to view] > 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 >
Hi Claudio,
There is nothing "evil" about multiple assemblies, and it may help reduce component coupling. If you do not want to deploy the application as multiple assemblies, merge them into one .exe file in a post-build step using ILMerge, a great free tool: http://research.microsoft.com/~mbarnett/ILMerge.aspx I believe the only "cons" of multiple assemblies are: - more complex deployment - slightly slower start up Regards, Frank Hileman check out VG.net: http://www.vgdotnet.com Animated vector graphics system Integrated Visual Studio .NET graphics editor "Claudio Pacciarini" <ClaudioPacciarini@discussions.microsoft.com> wrote in message news:7D7F2970-1951-41B2-8BB3-40DACBD882B8@microsoft.com... [quoted text, click to view] > 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.
Hi Scott and Frank,
Thanks for your kind responses. My intention is to help my team improve the way we design and develop some of our applications. Your email and all the rest of the emails I’ve been receiving will hopefully help me achieve that goal. Thanks so much. Claudio PS: Scott, your reference to the abacus was hilarious. :-) -- Claudio Pacciarini [quoted text, click to view] "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\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
;)
Good luck! "Claudio Pacciarini" <ClaudioPacciarini@discussions.microsoft.com> wrote in message news:253C108E-0BDE-4D4B-BC24-20E6EBB697A2@microsoft.com... [quoted text, click to view] > Hi Scott and Frank, > > Thanks for your kind responses. My intention is to help my team improve > the > way we design and develop some of our applications. Your email and all the > rest of the emails I've been receiving will hopefully help me achieve that > goal. > > Thanks so much. > > Claudio > > PS: Scott, your reference to the abacus was hilarious. :-) > > > -- > > 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\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 >>
Hi Greg,
Assume that the assembly is not loaded until you need it (I am not positive about this). If the application does not use those assemblies immediately, yes you are correct, it is faster. But if the assemblies are needed immediately at startup, it is faster to load a single assembly. Regards, Frank Hileman check out VG.net: http://www.vgdotnet.com Animated vector graphics system Integrated Visual Studio .NET graphics editor [quoted text, click to view] "Greg Young" <druckdruckREMOVEgoose@hotmail.com> wrote in message news:uPaFiRatGHA.1504@TK2MSFTNGP03.phx.gbl... > How would it be slower startup? In most cases it should be faster as not > all of the assemblies/types will be loaded at startup but rather loaded > later when needed.
How would it be slower startup? In most cases it should be faster as not all
of the assemblies/types will be loaded at startup but rather loaded later when needed. Cheers, Greg Young MVP - C# http://codebetter.com/blogs/gregyoung [quoted text, click to view] "Frank Hileman" <frankhil@no.spamming.prodigesoftware.com> wrote in message news:ejlRL8JtGHA.4324@TK2MSFTNGP05.phx.gbl... > Hi Claudio, > > There is nothing "evil" about multiple assemblies, and it may help reduce > component coupling. If you do not want to deploy the application as > multiple assemblies, merge them into one .exe file in a post-build step > using ILMerge, a great free tool: > > http://research.microsoft.com/~mbarnett/ILMerge.aspx > > I believe the only "cons" of multiple assemblies are: > - more complex deployment > - slightly slower start up > > Regards, > Frank Hileman > > check out VG.net: http://www.vgdotnet.com > Animated vector graphics system > Integrated Visual Studio .NET graphics editor > > > "Claudio Pacciarini" <ClaudioPacciarini@discussions.microsoft.com> wrote > in message news:7D7F2970-1951-41B2-8BB3-40DACBD882B8@microsoft.com... >> 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. > >
Hi Scott,
It only makes sense to ILMerge assemblies that are not going into the GAC, or may be missing from the GAC... The main point is simplifying deployment. Fewer file accesses can be a plus as well. Or if the assembly is loaded in Internet Explorer, fewer server round trips. GAC based assemblies use less memory when shared between processes, so there is no reason to merge them if they will definitely be present in the GAC. We use ILMerge to simplify demo deployment. A single executable in a zip file can be run in place without extracting an executable and a set of dlls. Another use for ILMerge is to make all symbols internal to the executable, then rename them with an obfuscator, reducing the total size of the final distribution. Regards, Frank Hileman check out VG.net: http://www.vgdotnet.com Animated vector graphics system Integrated Visual Studio .NET graphics editor [quoted text, click to view] "Scott M." <s-mar@nospam.nospam> wrote in message news:O3Y78fbtGHA.2260@TK2MSFTNGP03.phx.gbl... > Not necessarially. If the needed assemblies are installed into the GAC, > there is a chance that some other application may have already called for > the assembly, in which case, it would already be loaded when this > application needs it.
[quoted text, click to view]
> Assume that the assembly is not loaded until you need it (I am not > positive about this). Not an assumption. In .NET, it's a fact. [quoted text, click to view] >If the application does not use those assemblies immediately, yes you are >correct, it is faster. But if the assemblies are needed immediately at >startup, it is faster to load a single assembly. Not necessarially. If the needed assemblies are installed into the GAC, there is a chance that some other application may have already called for the assembly, in which case, it would already be loaded when this application needs it. [quoted text, click to view] > > Regards, > Frank Hileman > > check out VG.net: http://www.vgdotnet.com > Animated vector graphics system > Integrated Visual Studio .NET graphics editor > > "Greg Young" <druckdruckREMOVEgoose@hotmail.com> wrote in message > news:uPaFiRatGHA.1504@TK2MSFTNGP03.phx.gbl... >> How would it be slower startup? In most cases it should be faster as not >> all of the assemblies/types will be loaded at startup but rather loaded >> later when needed. > >
I wasn't referring to IL merged assemblies. I was talking about assemblies
in general. [quoted text, click to view] "Frank Hileman" <frankhil@no.spamming.prodigesoftware.com> wrote in message news:e5tPTjctGHA.4872@TK2MSFTNGP02.phx.gbl... > Hi Scott, > > It only makes sense to ILMerge assemblies that are not going into the GAC, > or may be missing from the GAC... The main point is simplifying > deployment. Fewer file accesses can be a plus as well. Or if the assembly > is loaded in Internet Explorer, fewer server round trips. > > GAC based assemblies use less memory when shared between processes, so > there is no reason to merge them if they will definitely be present in the > GAC. > > We use ILMerge to simplify demo deployment. A single executable in a zip > file can be run in place without extracting an executable and a set of > dlls. > > Another use for ILMerge is to make all symbols internal to the executable, > then rename them with an obfuscator, reducing the total size of the final > distribution. > > Regards, > Frank Hileman > > check out VG.net: http://www.vgdotnet.com > Animated vector graphics system > Integrated Visual Studio .NET graphics editor > > > "Scott M." <s-mar@nospam.nospam> wrote in message > news:O3Y78fbtGHA.2260@TK2MSFTNGP03.phx.gbl... >> Not necessarially. If the needed assemblies are installed into the GAC, >> there is a chance that some other application may have already called for >> the assembly, in which case, it would already be loaded when this >> application needs it. > >
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |