Why use DLLs?

[Florian]

Hi,

I have a question regarding Application Development and the usage of
DLLs. Because my EXE is growing I'm not sure if I should put some code
into a DLL. But what kind of code should I put there? In my
unserstanding it only make sense for code wich isn't often used. At
which size does it make sense?
thx

[Jon Skeet [C# MVP]]

Florian <ve******@gmx.ch> wrote:

I have a question regarding Application Development and the usage of
DLLs. Because my EXE is growing I'm not sure if I should put some code
into a DLL. But what kind of code should I put there? In my
unserstanding it only make sense for code wich isn't often used. At
which size does it make sense?

On the contrary - libraries are ideal for code which *is* often used -
by different applications. If you have two applications, both of which
want to use a bunch of the same classes, you can put those classes in a
library, and both applications can reference the same library.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Niki Estner]

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in
news:MP************************@msnews.microsoft.c om...

Florian <ve******@gmx.ch> wrote:

I have a question regarding Application Development and the usage of
DLLs. Because my EXE is growing I'm not sure if I should put some code
into a DLL. But what kind of code should I put there? In my
unserstanding it only make sense for code wich isn't often used. At
which size does it make sense?

On the contrary - libraries are ideal for code which *is* often used -
by different applications. If you have two applications, both of which
want to use a bunch of the same classes, you can put those classes in a
library, and both applications can reference the same library.

In addition to that, DLL's also help structuring an application: You can
develop and test them separately (maybe by separate people, too).
Maintainance is also often easier, as responsibilities between different
assemblies (DLL's and EXE's) are clearer.

And, DLL's are also often used for optional code parts: If a certain feature
is only needed by some of your customers, you can put it into a DLL, and (if
the DLL is loaded dynamically) deploy that DLL only on PCs where it's
needed.

Niki

[Peter Rilling]

My design philosophy is that almost all code should go in a DLL and that the
EXE would contain minimal logic. The best EXE will have only a simple main
function that processes the commandline arguments and passes that
information to classes from the library.

"Niki Estner" <ni*********@cube.net> wrote in message
news:uE**************@TK2MSFTNGP12.phx.gbl...

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in
news:MP************************@msnews.microsoft.c om...

Florian <ve******@gmx.ch> wrote:

I have a question regarding Application Development and the usage of
DLLs. Because my EXE is growing I'm not sure if I should put some code
into a DLL. But what kind of code should I put there? In my
unserstanding it only make sense for code wich isn't often used. At
which size does it make sense?
On the contrary - libraries are ideal for code which *is* often used -
by different applications. If you have two applications, both of which
want to use a bunch of the same classes, you can put those classes in a
library, and both applications can reference the same library.

In addition to that, DLL's also help structuring an application: You can
develop and test them separately (maybe by separate people, too).
Maintainance is also often easier, as responsibilities between different
assemblies (DLL's and EXE's) are clearer.

And, DLL's are also often used for optional code parts: If a certain

feature is only needed by some of your customers, you can put it into a DLL, and (if the DLL is loaded dynamically) deploy that DLL only on PCs where it's
needed.

Niki

[Jay B. Harlow [MVP - Outlook]]

Florian,
As Peter suggested, my EXE's tend to be smaller, while most of the actual
"program" logic is in various DLLs. Which may or may not be shared across
applications.

Normally my DLL's follow the logical tiers of my application.

For example:

MyApp.Exe
MyApp.Framework.dll
MyApp.Plugin1.dll
MyApp.Plugin2.dll
MyApp.Data.dll
MyApp.UI.dll
MyApp.SomeSubSystem.dll
...
Another example: I have a Windows Service that is organized as:

MyApp.Manager.exe (a Windows Forms Program)
MyApp.Service.exe (a Windows Service)
MyApp.Framework.dll (a class library)

The Server & Manager both call into the Framework to perform actions.

Hope this helps
Jay

"Florian" <ve******@gmx.ch> wrote in message
news:ed**************************@posting.google.c om...

Hi,

I have a question regarding Application Development and the usage of
DLLs. Because my EXE is growing I'm not sure if I should put some code
into a DLL. But what kind of code should I put there? In my
unserstanding it only make sense for code wich isn't often used. At
which size does it make sense?
thx

[John Timney \(ASP.NET MVP\)]

I have to agree too, keep your interface as lightweight as possible and put
your business logic in a business layer. Its the principle of multi-tiered
applications and you'll reap the benefits in the long run. That said,
sometime its quicker and cheaper to hack your code into a single exe if you
cant think of a scenario in your environment where you might need
reusability.

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director

"Peter Rilling" <pe***@nospam.rilling.net> wrote in message
news:e%****************@tk2msftngp13.phx.gbl...

My design philosophy is that almost all code should go in a DLL and that the EXE would contain minimal logic. The best EXE will have only a simple main function that processes the commandline arguments and passes that
information to classes from the library.

"Niki Estner" <ni*********@cube.net> wrote in message
news:uE**************@TK2MSFTNGP12.phx.gbl...

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in
news:MP************************@msnews.microsoft.c om...

Florian <ve******@gmx.ch> wrote:
> I have a question regarding Application Development and the usage of
> DLLs. Because my EXE is growing I'm not sure if I should put some code> into a DLL. But what kind of code should I put there? In my
> unserstanding it only make sense for code wich isn't often used. At
> which size does it make sense?

On the contrary - libraries are ideal for code which *is* often used -
by different applications. If you have two applications, both of which
want to use a bunch of the same classes, you can put those classes in a library, and both applications can reference the same library.

In addition to that, DLL's also help structuring an application: You can
develop and test them separately (maybe by separate people, too).
Maintainance is also often easier, as responsibilities between different
assemblies (DLL's and EXE's) are clearer.

And, DLL's are also often used for optional code parts: If a certain

feature

is only needed by some of your customers, you can put it into a DLL, and

(if

the DLL is loaded dynamically) deploy that DLL only on PCs where it's
needed.

Niki

[Marc Scheuner [MVP ADSI]]

>I have a question regarding Application Development and the usage of

DLLs. Because my EXE is growing I'm not sure if I should put some code
into a DLL. But what kind of code should I put there? In my
unserstanding it only make sense for code wich isn't often used. At
which size does it make sense?

You can easily leave it as it is - unless you have a dozen or so
different apps that would all be using the same code (in that case,
put all the common code into one or multiple DLL's).

Having DLL's can achieve two main things:

* Reduce the code size (on disk) by sharing common code amongst
applications - not such a great issue anymore with multi-gigabyte
harddisks

* Make apps more easily maintainable, since you might be able to
upgrade some of the app's functionality by simply replacing a DLL (or
multiple DLLs) that contain the code implementing the functionality.

Also, using a DLL-based plugin system can make your app more easily
extensible.

But all in all, if you have just basically one app and don't need
dynamic extensions, you can easily leave everything in one big EXE.

Marc

================================================== ==============
Marc Scheuner May The Source Be With You!
Bern, Switzerland m.scheuner(at)inova.ch

[Florian]

Hi,
thx for the answers. Does that mean that a DLL should be written for
every logical part (namespace) in an application? Isn't there a big
overhead for dll loading? So If I write a application with DB Access I
have all the classes for the Datamodel in a DLL ,a DLL for the DB
Access and a DLL for the GUI, when all the Layers are on the Client?

thx again
Florian

[Niki Estner]

"Florian" <ve******@gmx.ch> wrote in
news:ed**************************@posting.google.c om...

Hi,
thx for the answers. Does that mean that a DLL should be written for
every logical part (namespace) in an application?
This is really largely a matter of taste, but it's not uncommon.
Isn't there a big overhead for dll loading?

No. Loading code from an EXE file or from an DLL file shouldn't make any
difference.

Niki

[Marc Scheuner [MVP ADSI]]

>thx for the answers. Does that mean that a DLL should be written for

every logical part (namespace) in an application?

No, I wouldn't create a DLL for every namespace - I would create a DLL
for every logically separate part of your app, especially those which
you might want to extend dynamically (e.g. import filters on a
graphics display program etc.). We normally create separate DLL's for

* database access
* business logic layer
* UI code
* utility / shared code

plus a main app's EXE tying everything together.

MArc
================================================== ==============
Marc Scheuner May The Source Be With You!
Bern, Switzerland m.scheuner(at)inova.ch

[Raj]

Hi,
Sorry to poke my nose in the conversation…
I am doing exactly the same splitting things up as …
< *database access

* business logic layer
* UI code
* utility / shared code

But, I am developing a large application which currently holds about
100 forms in the UI(I think its going to get 200 forms in total) I do
reuse the forms when ever possible. Right now my application exe size
is 2.5 MB.

So I need to know is it *Bad* to have big exe? If so how to reduce it?
I thought of splitting the UI into the multiple dlls but, it's not
possible as the forms need to communicate with each other.

I would appreciate any feedback or suggestions

Thanks

RK

Marc Scheuner [MVP ADSI] <m.********@inova.SPAMBEGONE.ch> wrote in message news:<a4********************************@4ax.com>. ..

thx for the answers. Does that mean that a DLL should be written for
every logical part (namespace) in an application?

No, I wouldn't create a DLL for every namespace - I would create a DLL
for every logically separate part of your app, especially those which
you might want to extend dynamically (e.g. import filters on a
graphics display program etc.). We normally create separate DLL's for

* database access
* business logic layer
* UI code
* utility / shared code

plus a main app's EXE tying everything together.

MArc
================================================== ==============
Marc Scheuner May The Source Be With You!
Bern, Switzerland m.scheuner(at)inova.ch

[Niki Estner]

"Raj" <Ra***********@Hotmail.com> wrote in
news:a0**************************@posting.google.c om...

Hi,
Sorry to poke my nose in the conversation.
This is a public newsgroup. I always thought anyone was invited to post
here?
I am doing exactly the same splitting things up as .
< *database access

* business logic layer
* UI code
* utility / shared code
But, I am developing a large application which currently holds about
100 forms in the UI(I think its going to get 200 forms in total) I do
reuse the forms when ever possible. Right now my application exe size
is 2.5 MB.

So I need to know is it *Bad* to have big exe?

It certainly needs more memory, but splitting it into DLLs wouldn't change
that. Things don't get inefficient or something like that (to the best of my
knowledge), if that's what you meant.
If so how to reduce it?

Reduce redundancy. Hard to give you any better advice without facts. Given
the number of 200 forms, maybe it would be efficient to build some kind of
generic data-input (or whatever) form that can be reused heavily (e.g. you
could populate it by using reflection, inserting an appropriate control for
each member in a class?)

Niki

[Raj]

Thanks Niki for the feedback

Currently i have about 100 forms, i am assuming that it could reach
200 figure!
All these forms have been reused multiple times so i do not think that
is an option now.
Only idea behind the reducing the size being easy updates(Physical
transfer of files) on all the clients.
I am thinking since my application is an intranet application i should
build some kind of auto update feature to the application(some thing
like a Microsoft's smart client), so that this contraint will be
minimized
I know if i tried to build a dll for each of my forms its going to be
bigger mess than ever trying to manage components individually.

Thanks again
Raj
"Niki Estner" <ni*********@cube.net> wrote in message news:<uo**************@TK2MSFTNGP11.phx.gbl>...

"Raj" <Ra***********@Hotmail.com> wrote in
news:a0**************************@posting.google.c om...

Hi,
Sorry to poke my nose in the conversation.

This is a public newsgroup. I always thought anyone was invited to post
here?

I am doing exactly the same splitting things up as .
< *database access

* business logic layer
* UI code
* utility / shared code

But, I am developing a large application which currently holds about
100 forms in the UI(I think its going to get 200 forms in total) I do
reuse the forms when ever possible. Right now my application exe size
is 2.5 MB.

So I need to know is it *Bad* to have big exe?

It certainly needs more memory, but splitting it into DLLs wouldn't change
that. Things don't get inefficient or something like that (to the best of my
knowledge), if that's what you meant.

If so how to reduce it?

Reduce redundancy. Hard to give you any better advice without facts. Given
the number of 200 forms, maybe it would be efficient to build some kind of
generic data-input (or whatever) form that can be reused heavily (e.g. you
could populate it by using reflection, inserting an appropriate control for
each member in a class?)

Niki

[Marc Scheuner [MVP ADSI]]

>Right now my application exe size is 2.5 MB.

So I need to know is it *Bad* to have big exe?

No - Windows will only load whatever parts it actually needs - it
won't load the whole EXE into memory (as long as you don't poke around
it with e.g. EXE compressors etc.).

So it might be a problem in terms of deployment (you need to copy out
your 2.5 MB EXE file to all your customers, whenever there's an
update), but other than that, and especially at runtime, there's no
significant drawback to having a large EXE file.

Marc

================================================== ==============
Marc Scheuner May The Source Be With You!
Bern, Switzerland m.scheuner(at)inova.ch

[Miss]

Thanks Marc

That's what I wanted to hear(or confirm)

Raj
"Marc Scheuner [MVP ADSI]" <m.********@inova.SPAMBEGONE.ch> wrote in message
news:n5********************************@4ax.com...

Right now my application exe size is 2.5 MB.
So I need to know is it *Bad* to have big exe?

No - Windows will only load whatever parts it actually needs - it
won't load the whole EXE into memory (as long as you don't poke around
it with e.g. EXE compressors etc.).

So it might be a problem in terms of deployment (you need to copy out
your 2.5 MB EXE file to all your customers, whenever there's an
update), but other than that, and especially at runtime, there's no
significant drawback to having a large EXE file.

Marc

================================================== ==============
Marc Scheuner May The Source Be With You!
Bern, Switzerland m.scheuner(at)inova.ch