|
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 
If you can't read my code, try converting it here[^]
|
|
|
|
|
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>
|
|
|
|
|
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 
Bastard Programmer from Hell
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.
|
|
|
|
|
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.
|
|
|
|
|
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 Program class, 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
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.
|
|
|
|
|
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:
|
|
|
|
|
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?
|
|
|
|
|
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.
|
|
|
|
|
+5
"Let's make a shared library out of that code"
"Lets us ILMerge those"
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
If you can't read my code, try converting it here[^]
|
|
|
|
|
Oh, you've done SSIS too? 
|
|
|
|
|
I wouldn't want to do either and nothing about my question implies I would.
|
|
|
|
|
By wrapping everything in an executable you're just adding extra dead weight.
|
|
|
|
|
Do you know how much and if so is it a constant amount?
|
|
|
|
|
It's not constant as the sizes of various tables in the resulting .EXE change depending on what is in the .EXE.
|
|
|
|
|
A single static method. How much do they weigh?
..and now in metric? 
Bastard Programmer from Hell
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.
|
|
|
|
|
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 think Dave is also concerned about size in memory (when referenced normally), which is harder to measure.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
