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?
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 -
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 -
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 -
My thinking was along similar lines i.e. writing small executables that did one thing but did it well a la UNIX. Except I would require that the default behaviour of a main() function was to run a test suite embedded in the assembly.
You can have a static
int Test(string[] args)for that (unless you plan on using debug, vs stdout). Call it with the help of a shell-extension or external command that loads the assembly and executes your custom entrypoint :rolleyes:Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
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 -
Sounds 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.
When was the last time you executed unit tests on customer site? I've written seperate tools to diagnose database problems, but never to verify "the code". If the .EXE gets corrupted, chances are good it won't even run, and if it is corrupted, chances are good you've got hardware problems.
A guide to posting questions on CodeProject
Click this: Asking questions is a skill. Seriously, do it.
Dave Kreskowiak
