ILMerge...Why?

Discussion in 'Microsoft C# .NET' started by Todd Carnes, Jul 20, 2008.

  1. Todd Carnes

    Todd Carnes Guest

    I have read several threads regarding using ILMerge to combine all your
    dlls with your exe to create one single exe file....I don't get it.

    Why would you ever want to do this?

    Todd
     
    Todd Carnes, Jul 20, 2008
    #1
    1. Advertisements

  2. Todd Carnes wrote:
    > I have read several threads regarding using ILMerge to combine all your
    > dlls with your exe to create one single exe file....I don't get it.
    >
    > Why would you ever want to do this?


    In most cases it is a bad idea, because you get multiple copies
    of the code in DLL's which is against the fundamental idea of DLL's.

    But it makes deployment slightly easier and in some cases that can
    justify it.

    Arne
     
    Arne Vajhøj, Jul 20, 2008
    #2
    1. Advertisements

  3. Todd,

    >
    > Why would you ever want to do this?
    >

    May I ask you this with a question.

    Why would you never want to do this?

    Cor
     
    Cor Ligthert[MVP], Jul 20, 2008
    #3
  4. Todd Carnes

    Todd Carnes Guest

    Cor Ligthert[MVP] wrote:
    > Todd,
    >
    >>
    >> Why would you ever want to do this?
    >>

    > May I ask you this with a question.
    >
    > Why would you never want to do this?
    >
    > Cor


    Because I think it defeats the whole purpose of using dlls to begin
    with. It seems like a step backwards to me. If you are going to stuff
    all your code into one monolithic file, you might as well return to
    using DOS as well.

    But what do I know? :)

    I thought the whole idea of dll's, as well as so's on Linux systems, was
    that they could be unloaded from memory when not in use and that more
    than one program can use them, thus saving disk space and saving time &
    money (because you don't have to re-invent the wheel every time you
    write a new program). Surely, once you've used ILMerge to squash
    everything into one file this is no longer true, correct?

    Todd
     
    Todd Carnes, Jul 20, 2008
    #4
  5. Todd Carnes

    Todd Carnes Guest

    MC wrote:
    > "Todd Carnes" <> wrote in message
    > news:g5u24c$j6k$...
    >> I have read several threads regarding using ILMerge to combine all your
    >> dlls with your exe to create one single exe file....I don't get it.
    >>
    >> Why would you ever want to do this?

    >
    > To deliver your product as a single .exe file that does not need any other
    > files or installation procedure. These are called "no-install programs" and
    > are a very welcome development (or revival of an old idea).
    >
    >


    Maybe I'm just being thick-headed here, but why is this "a very welcome
    development"?

    The whole idea off dll's is to get away from this. With a dll, if you
    issue a bug fix for the dll, you only have to fix the dll and every
    program that uses the dll gets the benefit of the fix. If you merge the
    dll with your program, your program will be tied to that version of the
    dll and you'll have to recompile your program every time a dll is changed.

    Granted, I can think of one situation where this "might" be advantageous
    (running the program from a portable media like a USB flash drive), but
    I can think of several situations where this might be considered a bad idea.

    Please understand, I am NOT trying to start an argument with this
    question. I really don't see the benefit and am trying to understand.

    Todd
     
    Todd Carnes, Jul 20, 2008
    #5
  6. Todd Carnes wrote:
    > MC wrote:
    >> "Todd Carnes" <> wrote in message
    >> news:g5u24c$j6k$...
    >>> I have read several threads regarding using ILMerge to combine all
    >>> your dlls with your exe to create one single exe file....I don't get it.
    >>>
    >>> Why would you ever want to do this?

    >>
    >> To deliver your product as a single .exe file that does not need any
    >> other files or installation procedure. These are called "no-install
    >> programs" and are a very welcome development (or revival of an old idea).

    >
    > Maybe I'm just being thick-headed here, but why is this "a very welcome
    > development"?
    >
    > The whole idea off dll's is to get away from this. With a dll, if you
    > issue a bug fix for the dll, you only have to fix the dll and every
    > program that uses the dll gets the benefit of the fix. If you merge the
    > dll with your program, your program will be tied to that version of the
    > dll and you'll have to recompile your program every time a dll is changed.
    >
    > Granted, I can think of one situation where this "might" be advantageous
    > (running the program from a portable media like a USB flash drive), but
    > I can think of several situations where this might be considered a bad
    > idea.


    Sometimes ease of deployment is the biggest priority.

    Arne
     
    Arne Vajhøj, Jul 21, 2008
    #6
  7. Todd Carnes

    J.B. Moreno Guest

    In article <g5vl8h$22g$>,
    Todd Carnes <> wrote:

    > Cor Ligthert[MVP] wrote:
    > > Todd,
    > >
    > >>
    > >> Why would you ever want to do this?
    > >>

    > > May I ask you this with a question.
    > >
    > > Why would you never want to do this?
    > >
    > > Cor

    >
    > Because I think it defeats the whole purpose of using dlls to begin
    > with. It seems like a step backwards to me. If you are going to stuff
    > all your code into one monolithic file, you might as well return to
    > using DOS as well.


    It's not a step backwards because dll's weren't a step forward -- they
    were a solution to a problem that almost was....

    > But what do I know? :)
    >
    > I thought the whole idea of dll's, as well as so's on Linux systems, was
    > that they could be unloaded from memory when not in use and that more
    > than one program can use them, thus saving disk space and saving time &
    > money (because you don't have to re-invent the wheel every time you
    > write a new program). Surely, once you've used ILMerge to squash
    > everything into one file this is no longer true, correct?


    You don't need DLL's to unload the code out of memory, and hard disk
    space hasn't been an issue for anybody (including MS) since gigabyte
    hard drives came out.

    Back in the late 80's code size for major applications briefly
    outstripped the available disk size when installed on on slightly older
    systems. But in the last 20 years it's been the rare developer that
    needed more hard drive space than was available on the average users
    system. Today it's practically impossible to even get a user to think
    about it.

    Code reuse is a different matter, and in a way it's the saving grace of
    DLLs. They limped along for a decade looking for a problem to solve,
    one eventually came along -- the internet and interactive web page.

    But unless you're working on a program that is going to have a web
    based front end, or needs some other kind of distributed execution,
    dlls just aren't of much benefit.

    --
    J.B. Moreno
     
    J.B. Moreno, Jul 21, 2008
    #7
  8. J.B. Moreno,

    As I would have written almost the same as you, I just want to add one word
    near my opinion,

    > dlls just aren't of much benefit


    anymore.

    :)

    Cor
     
    Cor Ligthert[MVP], Jul 21, 2008
    #8
  9. Todd Carnes

    Peter Morris Guest

    Dynamic loading is still a big benefit for plugin type systems.
     
    Peter Morris, Jul 21, 2008
    #9
  10. Todd Carnes

    Todd Carnes Guest

    J.B. Moreno wrote:
    > You don't need DLL's to unload the code out of memory, and hard disk
    > space hasn't been an issue for anybody (including MS) since gigabyte
    > hard drives came out.


    I do see your point about the disk space, but just because you have
    gigabytes of space available, doesn't mean you should use gigabytes of
    space. :)

    Also, although I can already hear the objections that will be raised on
    this point, size DOES matter to those who want to download a program,
    but are not fortunate enough to have access to super-fast internet
    connections. Believe it or not there are still plenty of people out
    there who are forced to either use a dial-up connection or not have
    internet at all....

    I know this because until recently I was one of those people who still
    only had a 28k (not even 56k) dial-up connection because that was all
    that was available where I lived. (LOL... Thank goodness, I moved.)

    [snip]

    > Code reuse is a different matter, and in a way it's the saving grace of
    > DLLs. They limped along for a decade looking for a problem to solve,
    > one eventually came along -- the internet and interactive web page.
    >
    > But unless you're working on a program that is going to have a web
    > based front end, or needs some other kind of distributed execution,
    > dlls just aren't of much benefit.
    >


    I don't work on programs with web-based front-ends, but I still use dlls
    for code reuse. Why would I want to write the same code over and over
    again when I can just write it once, store it in a dll and then use it
    with as many programs as I want?

    Todd

    P.S. Thanks to everyone participating in this thread. I'm learning a
    lot. (even if it might not seem like it at times <grin>)
     
    Todd Carnes, Jul 22, 2008
    #10
  11. Todd Carnes

    Todd Carnes Guest

    Arne Vajhøj wrote:
    > Todd Carnes wrote:
    >> I have read several threads regarding using ILMerge to combine all
    >> your dlls with your exe to create one single exe file....I don't get it.
    >>
    >> Why would you ever want to do this?

    >
    > In most cases it is a bad idea, because you get multiple copies
    > of the code in DLL's which is against the fundamental idea of DLL's.
    >
    > But it makes deployment slightly easier and in some cases that can
    > justify it.


    May I ask you for an example when it would be justified?

    Todd
     
    Todd Carnes, Jul 22, 2008
    #11
  12. Todd Carnes

    J.B. Moreno Guest

    Todd Carnes <> wrote:

    > J.B. Moreno wrote:
    > > You don't need DLL's to unload the code out of memory, and hard disk
    > > space hasn't been an issue for anybody (including MS) since gigabyte
    > > hard drives came out.

    >
    > I do see your point about the disk space, but just because you have
    > gigabytes of space available, doesn't mean you should use gigabytes of
    > space. :)


    No, of course not...but are you building an application that requires
    gigabytes of space?

    > Also, although I can already hear the objections that will be raised on
    > this point, size DOES matter to those who want to download a program,
    > but are not fortunate enough to have access to super-fast internet
    > connections. Believe it or not there are still plenty of people out
    > there who are forced to either use a dial-up connection or not have
    > internet at all....
    >
    > I know this because until recently I was one of those people who still
    > only had a 28k (not even 56k) dial-up connection because that was all
    > that was available where I lived. (LOL... Thank goodness, I moved.)


    Well, until fairly recently I didn't even see 28k (19-24 was the norm),
    so I do understand....but in most cases DLL's won't make a difference.

    2 out of 3 things have to be true for DLL'S to matter in regards to
    size, 1 I'll take as a given (lack of access to a decent patcher
    program), but the other two....

    2. Frequent updates to PART of the program
    3. Multiple programs installed on the users computer that share a
    large amount of code.

    DLL's don't help with the initial download, only subsequent downloads
    and d

    > [snip]
    >
    > > Code reuse is a different matter, and in a way it's the saving grace of
    > > DLLs. They limped along for a decade looking for a problem to solve,
    > > one eventually came along -- the internet and interactive web page.
    > >
    > > But unless you're working on a program that is going to have a web
    > > based front end, or needs some other kind of distributed execution,
    > > dlls just aren't of much benefit.
    > >

    >
    > I don't work on programs with web-based front-ends, but I still use dlls
    > for code reuse. Why would I want to write the same code over and over
    > again when I can just write it once, store it in a dll and then use it
    > with as many programs as I want?


    You can statically link against the same code -- dynamic linking is
    useful when the code you're "reusing" changes faster than the code
    using it (this is the case for plug-in's for instance), or is outside
    your control.

    Don't get me wrong, I'm not saying that they are never appropriate and
    wouldn't necessarily recommend using ILMerge. But I would recommend
    taking a look at your proposed usage before breaking things out into
    separate DLL's.

    --
    J.B. Moreno
     
    J.B. Moreno, Jul 22, 2008
    #12
  13. Todd Carnes

    Todd Carnes Guest

    J.B. Moreno wrote:
    > Todd Carnes <> wrote:
    >
    >> J.B. Moreno wrote:
    >>> You don't need DLL's to unload the code out of memory, and hard disk
    >>> space hasn't been an issue for anybody (including MS) since gigabyte
    >>> hard drives came out.

    >> I do see your point about the disk space, but just because you have
    >> gigabytes of space available, doesn't mean you should use gigabytes of
    >> space. :)

    >
    > No, of course not...but are you building an application that requires
    > gigabytes of space?


    LOL, no, of course I'm not. I was exaggerating a bit to make a point. :)

    >> Also, although I can already hear the objections that will be raised on
    >> this point, size DOES matter to those who want to download a program,
    >> but are not fortunate enough to have access to super-fast internet
    >> connections. Believe it or not there are still plenty of people out
    >> there who are forced to either use a dial-up connection or not have
    >> internet at all....
    >>
    >> I know this because until recently I was one of those people who still
    >> only had a 28k (not even 56k) dial-up connection because that was all
    >> that was available where I lived. (LOL... Thank goodness, I moved.)

    >
    > Well, until fairly recently I didn't even see 28k (19-24 was the norm),
    > so I do understand....but in most cases DLL's won't make a difference.
    >
    > 2 out of 3 things have to be true for DLL'S to matter in regards to
    > size, 1 I'll take as a given (lack of access to a decent patcher
    > program), but the other two....
    >
    > 2. Frequent updates to PART of the program
    > 3. Multiple programs installed on the users computer that share a
    > large amount of code.
    >
    > DLL's don't help with the initial download, only subsequent downloads
    > and d


    You know, I hadn't looked at it in that way before. you make a good point.

    Thanks for taking the time to respond. :)

    Todd
     
    Todd Carnes, Jul 22, 2008
    #13
  14. Todd Carnes

    Joel Lucsy Guest

    Todd Carnes wrote:
    > I thought the whole idea of dll's, as well as so's on Linux systems, was
    > that they could be unloaded from memory when not in use and that more
    > than one program can use them, thus saving disk space and saving time &
    > money (because you don't have to re-invent the wheel every time you
    > write a new program). Surely, once you've used ILMerge to squash
    > everything into one file this is no longer true, correct?


    A couple of things. One, only AppDomains can be unloaded. Therefore,
    statically linked assemblies can not be unloaded.
    Two, there is an overhead for loading assemblies. Perhaps nothing
    noticeable for a handful of assemblies, but if you're breaking
    everything out in 10's or 100's of assemblies, your load time of the
    application will increase significantly. By ILMerge'ing them into a
    single EXE you can reduce this overhead.

    --
    Joel Lucsy
    "The dinosaurs became extinct because they didn't have a space program."
    -- Larry Niven
     
    Joel Lucsy, Jul 23, 2008
    #14
  15. Todd Carnes wrote:
    > Arne Vajhøj wrote:
    >> Todd Carnes wrote:
    >>> I have read several threads regarding using ILMerge to combine all
    >>> your dlls with your exe to create one single exe file....I don't get it.
    >>>
    >>> Why would you ever want to do this?

    >>
    >> In most cases it is a bad idea, because you get multiple copies
    >> of the code in DLL's which is against the fundamental idea of DLL's.
    >>
    >> But it makes deployment slightly easier and in some cases that can
    >> justify it.

    >
    > May I ask you for an example when it would be justified?


    The obvious one is if for whatever reasons requirements:
    - must be distributable as a single file
    - must run as is without any installation
    - must be a windows app not a web app
    have been cast in stone.

    Arne
     
    Arne Vajhøj, Jul 28, 2008
    #15
  16. Todd Carnes

    Arne Vajhøj Guest

    J.B. Moreno wrote:
    > Code reuse is a different matter, and in a way it's the saving grace of
    > DLLs. They limped along for a decade looking for a problem to solve,
    > one eventually came along -- the internet and interactive web page.
    >
    > But unless you're working on a program that is going to have a web
    > based front end, or needs some other kind of distributed execution,
    > dlls just aren't of much benefit.


    What ??

    Modularization of the deployment model is essential for
    a decent development process.

    Building everything to a big EXE does not work at all
    for large projects.

    I would be skeptical about it working even for medium
    size projects.

    Arne
     
    Arne Vajhøj, Jul 28, 2008
    #16
  17. Todd Carnes

    J.B. Moreno Guest

    Arne Vajhøj <> wrote:

    > J.B. Moreno wrote:
    > > Code reuse is a different matter, and in a way it's the saving grace of
    > > DLLs. They limped along for a decade looking for a problem to solve,
    > > one eventually came along -- the internet and interactive web page.
    > >
    > > But unless you're working on a program that is going to have a web
    > > based front end, or needs some other kind of distributed execution,
    > > dlls just aren't of much benefit.

    >
    > What ??
    >
    > Modularization of the deployment model is essential for
    > a decent development process.


    Deployment is part of the development process, but in most cases it
    shouldn't be driving it. If it is, then you probably have some kind of
    distributed execution system, and not a single application.


    > Building everything to a big EXE does not work at all
    > for large projects.


    How does it not work? And how about putting some numbers to "large"
    and "medium"?

    > I would be skeptical about it working even for medium
    > size projects.


    It sounds like you're talking systems, in which case yeah sure, you
    don't want to take down part of the system because you're updating
    another. But that's covered under distributed execution -- one
    user/one app works just fine when distributed as a single unit.

    --
    J.B. Moreno
     
    J.B. Moreno, Jul 28, 2008
    #17
  18. Todd Carnes

    Brian Gideon Guest

    On Jul 20, 10:37 am, Todd Carnes <> wrote:
    > The whole idea off dll's is to get away from this. With a dll, if you
    > issue a bug fix for the dll, you only have to fix the dll and every
    > program that uses the dll gets the benefit of the fix. If you merge the
    > dll with your program, your program will be tied to that version of the
    > dll and you'll have to recompile your program every time a dll is changed..


    There is a counter argument to that. The bug fix might actually break
    your application if your were relying on the behavior that the bug was
    causing. That's one (among many) reasons for testing your application
    if anything changes including its dependencies. I'm not saying this
    argument outweighs the benefits of using dlls though.
     
    Brian Gideon, Jul 28, 2008
    #18
  19. Todd Carnes

    Brian Gideon Guest

    On Jul 20, 5:58 am, "Cor Ligthert[MVP]" <>
    wrote:
    > Why would you never want to do this?


    I think using ILMerge requires more justification than not using it.
    Modularity, memory management, disk useage, and application
    maintenance represent a handful of benefits for using dlls that I
    could come up with off the top of head. Though, I can also think of
    scenarios where ILMerge would be useful.
     
    Brian Gideon, Jul 28, 2008
    #19
  20. Todd Carnes

    Arne Vajhøj Guest

    J.B. Moreno wrote:
    > Arne Vajhøj <> wrote:
    >> J.B. Moreno wrote:
    >>> Code reuse is a different matter, and in a way it's the saving grace of
    >>> DLLs. They limped along for a decade looking for a problem to solve,
    >>> one eventually came along -- the internet and interactive web page.
    >>>
    >>> But unless you're working on a program that is going to have a web
    >>> based front end, or needs some other kind of distributed execution,
    >>> dlls just aren't of much benefit.

    >> What ??
    >>
    >> Modularization of the deployment model is essential for
    >> a decent development process.

    >
    > Deployment is part of the development process, but in most cases it
    > shouldn't be driving it. If it is, then you probably have some kind of
    > distributed execution system, and not a single application.


    No.

    >> Building everything to a big EXE does not work at all
    >> for large projects.

    >
    > How does it not work?


    The teams producing different parts of the app becomes dependent
    on each other.

    > And how about putting some numbers to "large"
    > and "medium"?


    Those terms are not that well defined.

    But if you think:
    large is > 1 million LOC
    medium 100000-1 million LOC
    then you are not that far from me.

    >> I would be skeptical about it working even for medium
    >> size projects.

    >
    > It sounds like you're talking systems, in which case yeah sure, you
    > don't want to take down part of the system because you're updating
    > another. But that's covered under distributed execution -- one
    > user/one app works just fine when distributed as a single unit.


    I am talking development process - not operations.

    Arne
     
    Arne Vajhøj, Aug 2, 2008
    #20
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. bwahahahaha
    Replies:
    11
    Views:
    447
    Willy Denoyette [MVP]
    Oct 17, 2003
  2. William Stacey [MVP]

    http://research.microsoft.com/~mbarnett/ilmerge.as px

    William Stacey [MVP], Mar 22, 2004, in forum: Microsoft C# .NET
    Replies:
    2
    Views:
    172
    William Stacey [MVP]
    Mar 23, 2004
  3. rawCoder

    OT: ILMerge

    rawCoder, Mar 30, 2005, in forum: Microsoft C# .NET
    Replies:
    3
    Views:
    153
    Mohammad
    Mar 31, 2005
  4. Antonio Palermo

    ILMerge

    Antonio Palermo, May 24, 2005, in forum: Microsoft C# .NET
    Replies:
    6
    Views:
    223
    Antonio Palermo
    May 24, 2005
  5. JT

    GUIDs, snks, reflection and ILMerge

    JT, Dec 2, 2006, in forum: Microsoft C# .NET
    Replies:
    3
    Views:
    269
Loading...

Share This Page