Are DLLs redundant in .NET?
-
Having a separate console app that loads the Assembly would definitely be another way, but the only reason would be to simply remove the main, I don't see a big benefit.
-
Dave Kreskowiak wrote:
There is still unmanaged code in there to get the process running under the CLR
I'd be (at least a little) surprised if that got loaded with the Assembly when referenced in the usual way -- it ought to only affect disk usage except when executed (but then we're talking about Microsoft).
I just made a rough measure of this empirically: 1 class and 1 method DLL in release mode (4k on disk) vs EXE (5k on disk) 10 classes with 10 methods each in release mode gave DLL (7k on disk) and EXE (8k on disk) So the bloat increases far less than I'd consider to be significant. As for process start and CLR load.... remember we are just loading a library into an existing running CLR.
-
I was thinking: myProgram.exe -> runs a test suite myProgram.exe /run -> runs a traditional program if implemented or returns if it's a library
That sounds kinda backward to me.
-
I just made a rough measure of this empirically: 1 class and 1 method DLL in release mode (4k on disk) vs EXE (5k on disk) 10 classes with 10 methods each in release mode gave DLL (7k on disk) and EXE (8k on disk) So the bloat increases far less than I'd consider to be significant. As for process start and CLR load.... remember we are just loading a library into an existing running CLR.
I think Dave is also concerned about size in memory (when referenced normally), which is harder to measure.
-
I just made a rough measure of this empirically: 1 class and 1 method DLL in release mode (4k on disk) vs EXE (5k on disk) 10 classes with 10 methods each in release mode gave DLL (7k on disk) and EXE (8k on disk) So the bloat increases far less than I'd consider to be significant. As for process start and CLR load.... remember we are just loading a library into an existing running CLR.
Yeah, you're looking at disk usage, not in memory. If you want an idea of what overhead you're including, look at the Imports table in the .EXE.
A guide to posting questions on CodeProject
Click this: Asking questions is a skill. Seriously, do it.
Dave Kreskowiak -
Whilst prototyping a console app the other day, it stuck me that the dynamically linked library seemed somewhat redundant in .NET and that was nothing I could do with one that could not be achieved by creating an executable. I can add a reference and reuse publically declared types whilst with both. But an executable has some obvious benefits, yet I've always created DLLs because I've been told 'it's best practice' or just followed other's examples. Can anyone think of a technical reason why you'd choose to build a library over an executable? Is a DLL an artefact simply for some legacy backwards compatibility that I'm unaware of? Thoughts?
In a sense there is little difference between dlls and exes from the .NET perspective. I sometimes make code that is designed to be consumed by something (so would normally be a DLL) an .exe to support stand-alone use etc. My main point would be that they are conceptually different things. One is an application, the other is a reusable library. In a normal .NET deployment all your assemblies end up deployed in the same folder. Would you really want 20 .exes which don't do anything when you run them? It is a useful semantic distinction.
Regards, Rob Philpott.
-
Yeah, you're looking at disk usage, not in memory. If you want an idea of what overhead you're including, look at the Imports table in the .EXE.
A guide to posting questions on CodeProject
Click this: Asking questions is a skill. Seriously, do it.
Dave Kreskowiak -
I've now done the same using perfmon and don't see a significant overhead after taking the difference in process memory size. Can you point to more information on this subject?
Windows Internals 6th Edition, Part 1 and 2. Perfmon will only tell you exactly what you're telling it to, and only if the data is interpreted correctly.
A guide to posting questions on CodeProject
Click this: Asking questions is a skill. Seriously, do it.
Dave Kreskowiak -
Having a separate console app that loads the Assembly would definitely be another way, but the only reason would be to simply remove the main, I don't see a big benefit.
PIEBALDconsult wrote:
I don't see a big benefit.
You'd be separating the "testing" code from the code being tested. Better yet, put it in your own class, as opposed to the
Programclass, and get the benefits of inheritance. I can see how one would create an application that executes SQL from the command prompt, and references this as if it is a library to get the appropriate databaseclasses. Then again, you don't want to be referencing a WinApp application from a Webapplication and have it load the complete Forms-environment and all its dependencies.Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
PIEBALDconsult wrote:
I don't see a big benefit.
You'd be separating the "testing" code from the code being tested. Better yet, put it in your own class, as opposed to the
Programclass, and get the benefits of inheritance. I can see how one would create an application that executes SQL from the command prompt, and references this as if it is a library to get the appropriate databaseclasses. Then again, you don't want to be referencing a WinApp application from a Webapplication and have it load the complete Forms-environment and all its dependencies.Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
Eddy Vluggen wrote:
referencing a WinApp application from a Webapplication and have it load the complete Forms-environment and all its dependencies
I don't think we're talking about doing anything like that. Just a regular library, but with the ability to self-identify at the console.
-
Whilst prototyping a console app the other day, it stuck me that the dynamically linked library seemed somewhat redundant in .NET and that was nothing I could do with one that could not be achieved by creating an executable. I can add a reference and reuse publically declared types whilst with both. But an executable has some obvious benefits, yet I've always created DLLs because I've been told 'it's best practice' or just followed other's examples. Can anyone think of a technical reason why you'd choose to build a library over an executable? Is a DLL an artefact simply for some legacy backwards compatibility that I'm unaware of? Thoughts?
Well, in .Net it is called an assembly, but for your question it has the same function as a DLL or static library in Win32. An executable is usually a front end that the user executes and it can show a graphical user interface (GUI), a command line console interface or a web interface. An assembly is loaded into memory at run time and used by the executing application. What you want to achieve with a library/assembly is to compile code that is used over and over again into reusable modules. Look at all the references you add to your exe, they all contain code other people have written and you can reuse. Another way to reuse is to have compile the source code of the reusable classes into your exe, but that means that you need to have all source code available at all times. It means that every compilation might give you a slightly different functionality if you share code and someone make some changes in a class. If you use a specific version of an assembly you are pretty sure that you get what you wanted (assuming versions are used) This was a short explanation that could be much longer, and as an end note I boil it down to this: 1. No DLL's or assemblies are not obsolete. 2. Reuseability is the biggest advantage as I see it.