Are DLLs redundant in .NET?
-
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?
-
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?
CatchExAs wrote:
But an executable has some obvious benefits,
Like what? :confused: The only "benefit" an executable has over a library is that it can be executed directly. For the vast majority of class libraries, executing them doesn't make any sense. For example, what would you expect to happen if you executed
mscorlib?System.Data? Etc.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
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?
CatchExAs wrote:
Can anyone think of a technical reason why you'd choose to build a library over an executable?
..because the code is not an executable; that's the reason I did not include an entry point. If I put a logger into a separate assembly, I can easily swap it with another, without ever touching the executable. The logger-class does not need to run independently of the main executable. Same goes for most code. And yes, I've got some private projects where I use executables as if they are DLL's; it's just a collection of code after all.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
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?
One thing I have considered (but never actually done) is to have a library as an EXE so it can print out documentation (to the console) and maybe allow testing and demoing the functions contained therein. <aside> In OpenVMS, the analog of a DLL is a "shared executable", which generally has an EXE extension. </aside>
-
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?
So, how are you going to share your reusable code? Executables? Or are you going to cut and paste? Oh, and if you're adding a reference to something like a standard .NET assembly guess what, that's a DLL? Simply, a DLL is a convenient way to share functionality.
-
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?
Why would you want to make your code monolithic by including it in larger .EXE's, thereby increasing load time? Why would you want to give the users the ability to launch a "library" .EXE that does nothing but return to the command prompt?
A guide to posting questions on CodeProject
Click this: Asking questions is a skill. Seriously, do it.
Dave Kreskowiak -
One thing I have considered (but never actually done) is to have a library as an EXE so it can print out documentation (to the console) and maybe allow testing and demoing the functions contained therein. <aside> In OpenVMS, the analog of a DLL is a "shared executable", which generally has an EXE extension. </aside>
-
CatchExAs wrote:
But an executable has some obvious benefits,
Like what? :confused: The only "benefit" an executable has over a library is that it can be executed directly. For the vast majority of class libraries, executing them doesn't make any sense. For example, what would you expect to happen if you executed
mscorlib?System.Data? Etc.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
Why would you want to make your code monolithic by including it in larger .EXE's, thereby increasing load time? Why would you want to give the users the ability to launch a "library" .EXE that does nothing but return to the command prompt?
A guide to posting questions on CodeProject
Click this: Asking questions is a skill. Seriously, do it.
Dave KreskowiakDave Kreskowiak wrote:
make your code monolithic by including it in larger .EXE's
That's not what he means.
-
So, how are you going to share your reusable code? Executables? Or are you going to cut and paste? Oh, and if you're adding a reference to something like a standard .NET assembly guess what, that's a DLL? Simply, a DLL is a convenient way to share functionality.
Pete O'Hanlon wrote:
how are you going to share your reusable code?
The same way, but as an EXE with some sort of helpful library-specific functionality in the
main. :shrug: -
Dave Kreskowiak wrote:
make your code monolithic by including it in larger .EXE's
That's not what he means.
I know. I was just pointing out that some people can go overboard with the ILMerge tool and end up making an .EXE that's 10's or 100's of MB in size. Then they wonder why it takes so long to load.
A guide to posting questions on CodeProject
Click this: Asking questions is a skill. Seriously, do it.
Dave Kreskowiak -
Why would you want to make your code monolithic by including it in larger .EXE's, thereby increasing load time? Why would you want to give the users the ability to launch a "library" .EXE that does nothing but return to the command prompt?
A guide to posting questions on CodeProject
Click this: Asking questions is a skill. Seriously, do it.
Dave Kreskowiak -
What do you mean by "tested and verified themselves"??
A guide to posting questions on CodeProject
Click this: Asking questions is a skill. Seriously, do it.
Dave Kreskowiak -
By wrapping everything in an executable you're just adding extra dead weight.
A guide to posting questions on CodeProject
Click this: Asking questions is a skill. Seriously, do it.
Dave Kreskowiak -
What do you mean by "tested and verified themselves"??
A guide to posting questions on CodeProject
Click this: Asking questions is a skill. Seriously, do it.
Dave Kreskowiak -
Say, main() by default was required to call a bunch of test suites that executed unit tests. I once worked somewhere where they did this btw.
Soooo, you're going to ship your unit tests with the code to the customer? That sounds stupid. That's like shipping the Paint Shop from the assembly plant with the car that it built.
A guide to posting questions on CodeProject
Click this: Asking questions is a skill. Seriously, do it.
Dave Kreskowiak -
By wrapping everything in an executable you're just adding extra dead weight.
A guide to posting questions on CodeProject
Click this: Asking questions is a skill. Seriously, do it.
Dave Kreskowiak -
Soooo, you're going to ship your unit tests with the code to the customer? That sounds stupid. That's like shipping the Paint Shop from the assembly plant with the car that it built.
A guide to posting questions on CodeProject
Click this: Asking questions is a skill. Seriously, do it.
Dave KreskowiakSounds more like including the diagnostic reader device with the car rather than requiring a visit to the shop when the check engine light comes on.
-
Soooo, you're going to ship your unit tests with the code to the customer? That sounds stupid. That's like shipping the Paint Shop from the assembly plant with the car that it built.
A guide to posting questions on CodeProject
Click this: Asking questions is a skill. Seriously, do it.
Dave Kreskowiak -
It's not constant as the sizes of various tables in the resulting .EXE change depending on what is in the .EXE.
A guide to posting questions on CodeProject
Click this: Asking questions is a skill. Seriously, do it.
Dave Kreskowiak
