 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / C# / August 2008ILMerge...Why?
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 >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). >> 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. [quoted text clipped - 4 lines] > 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 >>> 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. [quoted text clipped - 18 lines] > I can think of several situations where this might be considered a bad > idea. Sometimes ease of deployment is the biggest priority. Arne > 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. > 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. I think it does. Things like this have happened many times. Programmers experiment to find out what a library function actually does -- if it doesn't match its documentation -- and they use it the way that actually works. Later, somebody changes it so it matches its documentation, instead of changing the documentation to match what was actually implemented, and the application breaks. > 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 >> 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. [quoted text clipped - 6 lines] > 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 >>> 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. [quoted text clipped - 8 lines] > > 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 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 > Todd, > [quoted text clipped - 5 lines] > > 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, > > [quoted text clipped - 10 lines] > 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? :) > [quoted text clipped - 4 lines] > 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.  SignatureJ.B. Moreno 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 Dynamic loading is still a big benefit for plugin type systems. > 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, [quoted text clipped - 3 lines] > 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>) > > 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 [quoted text clipped - 3 lines] > 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, [quoted text clipped - 6 lines] > 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] > [quoted text clipped - 10 lines] > 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. SignatureJ.B. Moreno >>> 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 [quoted text clipped - 5 lines] > 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, [quoted text clipped - 20 lines] > 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 > 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, [quoted text clipped - 3 lines] > 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 > > 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, [quoted text clipped - 8 lines] > 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. SignatureJ.B. Moreno >>> 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, [quoted text clipped - 11 lines] > 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. [quoted text clipped - 3 lines] > 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 -snip- > >> Modularization of the deployment model is essential for > >> a decent development process. [quoted text clipped - 4 lines] > > No. Either a distributed system or frequent updates -- otherwise what does it matter if they have to download X amount of data, unzip it it into Y number of files or 1 file? > >> Building everything to a big EXE does not work at all > >> for large projects. [quoted text clipped - 3 lines] > The teams producing different parts of the app becomes dependent > on each other. No more so than with static linking -- it adds an additional step, but everything else is otherwise unchanged. MSIs, ILMerge, VISE -- lots of tools to turn the deployment into a single application, there's really no difference between having a deployment application and having an application XCopy application deployment. The difference comes in when updating or extending it -- the initial download is the same. > > And how about putting some numbers to "large" and "medium"? > [quoted text clipped - 4 lines] > medium 100000-1 million LOC > then you are not that far from me. So maybe 5-50 meg for a medium and, 50+ for a large. On a fast connection, you don't even need to break it up into smaller pieces for frequent updates. On a slow connection, you better hope you don't have to do frequent updates because even portion is going to be slow... > >> I would be skeptical about it working even for medium > >> size projects. [quoted text clipped - 5 lines] > > I am talking development process - not operations. Then you're mixing things up -- if you're not actually using the dynamic loading (by which I mean switching to a newer version of the code without relinking on the users machine) then it doesn't gain you anything. SignatureJ.B. Moreno > 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 [quoted text clipped - 5 lines] > How does it not work? And how about putting some numbers to "large" > and "medium"? One thing to consider to here is that the CLR loader is very lazy. It will only load what it needs. I can't say with absolute certainty, but I suspect if everything were stuffed into one assembly then system resources could be negatively affected. Assuming that is the case then the conclusion is that the effect is proportional to the size of the project. > > 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 [quoted text clipped - 12 lines] > then the conclusion is that the effect is proportional to the size of > the project. just to add to this thread. I am a big fan of ilmerge, in my case it has nothing to do with dll's it has more to do with resource files. In my case, I have to distribute couple of resource files created another program (dynamically) need to be included in the final exe of one another program. In this case, I would like to use ILMerge and it works like a charm except the fact it has memory problems. > > 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 [quoted text clipped - 12 lines] > then the conclusion is that the effect is proportional to the size of > the project. That's possible, although extremely vague (and fallible) memory says that even within the same file the assemblies are distinct and only loaded as needed (and unloaded when not). SignatureJ.B. Moreno > > One thing to consider to here is that the CLR loader is very lazy. It > > will only load what it needs. I can't say with absolute certainty, [quoted text clipped - 6 lines] > that even within the same file the assemblies are distinct and only > loaded as needed (and unloaded when not). I don't know either. I suppose I could actually use ILMerge and examine the resultant assembly to make the determination, but that takes time. Anyone know for sure? > > > One thing to consider to here is that the CLR loader is very lazy. It > > > will only load what it needs. I can't say with absolute certainty, [quoted text clipped - 10 lines] > examine the resultant assembly to make the determination, but that > takes time. Anyone know for sure? Well, not about ILMerge but whether assemblies are unloaded depends upon whether they are loaded domain neutral or not...more later. SignatureJ.B. Moreno > 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. SignatureJoel Lucsy "The dinosaurs became extinct because they didn't have a space program." -- Larry Niven Actually, load time may decrease by breaking things out to DLLs. .Net only loads assemblies on demand, so until your program uses them, they sit on the disk unloaded. If on the other hand you've merged your DLLs into one file, the ENTIRE file must be read into memory before execution can begin. So I don't think this argument is a particularly sound one. > 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. > 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. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.