Are DLLs redundant in .NET?
-
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 -
Or a compiler that bootstraps and tests itself? Or an installable that operations can't fuck up? There are always reasons for questions ;-)
CatchExAs wrote:
Or a compiler that bootstraps and tests itself?
Really? How often do you see that and how often are you going to use it?
CatchExAs wrote:
Or an installable that operations can't f*** up?
Depending on what you mean by "operations", yeah, right. If you're talking about people, there's nothing they can't fuck up and there's always some situation that you're code isn't going to be able to recover from.
A guide to posting questions on CodeProject
Click this: Asking questions is a skill. Seriously, do it.
Dave Kreskowiak -
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+5 "Let's make a shared library out of that code" "Lets us ILMerge those" :omg: It is also done on the web, where they call it "packaging" or something like it. I wonder how many sites made me download a JQuery library that's already cached in the browser.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
It's the startup code, import tables, data tables, blah, blah, blah for a Win32 executable, that a .DLL doesn't have, nor need. A .NET assembly in an .EXE is not 100% MSIL code. There is still unmanaged code in there to get the process running under the CLR.
A guide to posting questions on CodeProject
Click this: Asking questions is a skill. Seriously, do it.
Dave Kreskowiak -
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 KreskowiakI never write or execute unit tests at all, anywhere. I don't have the same concerns as the OP and I don't think we're talking about DLLs shipped with an application, but libraries provided to other developers for use in their applications -- like if I wrote an ISO 8601-compliant date handling library for example, but only distributed the DLL rather than the code. Personally, when I get a DLL from some third-party (an ADO.net provider perhaps) I don't like having to create a Solution and Project, then add a reference just so I can use the Object Explorer to see what's in it. It would be convenient if it were an EXE and running it would provide (version-specific) documentation and such (hopefully more accurate than what's available on the developer's website, if any). Additionally, the Object Explorer only says what's in there, not how to use it, no documentation. I suspect there must already be a tool that allows sort of a command-line Object Explorer, but I haven't looked. Certainly one could be written, but it still wouldn't provide everything that a custom baked-in tool would. Seeing that given a DLL with some (public) class C with a (public) method M that takes a string parameter S and returns a string is all well and good, but wouldn't it be convenient to immediately be able to execute:
somelib test C.M "hello world"and have it report the result? Without having to access an IDE and write a simple test app just to see what it does? -
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[^]
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.
-
+5 "Let's make a shared library out of that code" "Lets us ILMerge those" :omg: It is also done on the web, where they call it "packaging" or something like it. I wonder how many sites made me download a JQuery library that's already cached in the browser.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
Oh, you've done SSIS too? :sigh:
-
It's the startup code, import tables, data tables, blah, blah, blah for a Win32 executable, that a .DLL doesn't have, nor need. A .NET assembly in an .EXE is not 100% MSIL code. There is still unmanaged code in there to get the process running under the CLR.
A guide to posting questions on CodeProject
Click this: Asking questions is a skill. Seriously, do it.
Dave KreskowiakDave 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).
-
CatchExAs wrote:
Or a compiler that bootstraps and tests itself?
Really? How often do you see that and how often are you going to use it?
CatchExAs wrote:
Or an installable that operations can't f*** up?
Depending on what you mean by "operations", yeah, right. If you're talking about people, there's nothing they can't fuck up and there's always some situation that you're code isn't going to be able to recover from.
A guide to posting questions on CodeProject
Click this: Asking questions is a skill. Seriously, do it.
Dave KreskowiakDave Kreskowiak wrote:
Really? How often do you see that and how often are you going to use it?
True, you see it rarely. But it is a useful technique to some, and so might be useful to others. You wouldn't know until you tried it.
Dave Kreskowiak wrote:
Depending on what you mean by "operations", yeah, right. If you're talking about people, there's nothing they can't f*** up and there's always some situation that you're code isn't going to be able to recover from.
Of course, which is why we automate things in the first place but the point is that the deployed binary can run tests on itself 'in situ' rather than a test environment which may or may not be representative of the target production environment.
-
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