|
What is it with some .NET developers and their desire to segregate their project into a billion different DLLs?
Nobody wants to install that. Nobody wants to deal with that. Stop it.
Is it a server application? No? Then go soak your head.
With a particular side-eye toward MonoTorrent.
Edit: I see I'm not alone in this sentiment. I thought I might have been a lone voice in the wilderness here. To the people that disagree, you raise some valid points, but I think context is important - there's a time and a place for lots of DLLs (like server code) and times when it's overdone. I'll cede that if you will.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
modified 7-May-19 10:23am.
|
|
|
|
|
codewitch honey crisis wrote: What is it with some .NET developers and their desire to segregate their project into a billion different DLLs?
Nobody wants to install that. Nobody wants to deal with that. Stop it.
Whenever I need to update part of the project, I simply upload the stuff that changed. Means that an update only affects what is changed. Keeps the download small (looking at you Steam!), makes the parts easier to manage.
I don't like to redownload a complete setup that contains 10Gb of crap that is already there. So please, keep it as modular.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
that's fair but i'm talking about lots of little 16k dlls and such.
if you can't manage that much source in a single project, there's something wrong with the way you're factoring your code, IMO.
Adding, with small apps that need to update I just make them update themselves by bootstrap
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
codewitch honey crisis wrote: that's fair but i'm talking about lots of little 16k dlls and such.
Which is perfect.
Do consider that a library is loaded on demand (when the runtime requires it). Put everything in an exe, and it is all loaded into memory before being executed.
It's not like an end-user need to know ANYTHING about what is present in the installation-folder, nor does the end-user need to manipulate those libs.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
i think it's a matter of degree. I'd put - for .NET - perfect being somewhere in the neighborhood of 150k and up, assuming generics are being used.
Adding, my criticism of the installbase is more from a dev and maintenance perspective. Sometimes there's such thing as overfactoring.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
codewitch honey crisis wrote: i think it's a matter of degree. I'd put - for .NET - perfect being somewhere in the neighborhood of 150k and up, assuming generics are being used.
Adding, my criticism of the installbase is more from a dev and maintenance perspective. Sometimes there's such thing as overfactoring.
Ah, did you expect my perspective to be that of a dairy-farmer? 
Sometimes I preload a DLL by calling a static method that does nothing. Forces the runtime to load the assembly and all its types. It makes life easier. Why would you prefer big executables containing duplicate code over that?
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
i meant as opposed to an end user's perspective
i just prefer to factor assemblies by related task.
i'm not sure what others do.
If I find myself with a little bit of redundancy at the source level, I have a mechanism for "includes" in C#.
If I find myself with a lot of it, that's where a separate assembly comes in.
YMMV
I don't see 150k as particularly large. .NET allocates 12 megabytes of heap as its way of saying "hi!"
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
codewitch honey crisis wrote: i meant as opposed to an end user's perspective
i just prefer to factor assemblies by related task.
i'm not sure what others do.
Others do "whatever works". I've often asked for motivations on behaviour, never get one.
codewitch honey crisis wrote: If I find myself with a little bit of redundancy at the source level, I have a mechanism for "includes" in C#.
If I find myself with a lot of it, that's where a separate assembly comes in.
Assume the programmer to be incompetent, and suddenly the rules that .NET abides to seem logical. If you don't use it, we don't load it. Assume your developers are VB6-fans.
And to be honest, as a professional developer, I like it that way.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
I get it, but maybe i'm just more of the Bastard Programmer from Hell than you are
Props for the reference though. BOFH is legend.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
codewitch honey crisis wrote: Props for the reference though. BOFH is legend.
Tx, meant as a tribute to BOFH. For one to see the reference makes me happy.
codewitch honey crisis wrote: I get it, but maybe i'm just more of the Bastard Programmer from Hell than you are
There's always a master to the master.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
LOL,
we have a 3rd party library that installs 2,083 small dlls.
I'd rather be phishing!
|
|
|
|
|
does it make you cringe a little?
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
especially when I have to update the installer packages.
I'd rather be phishing!
|
|
|
|
|
I can scarcely imagine. *pats you on the shoulder*
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Linnaeus-type programmers. They split everything up into deeply nested hierarchies of boxes-within-boxes-within-boxes. Not satisfied with the level of "separateness" provided by different class and different files and different namespaces, they will use different projects, and even different repositories.
|
|
|
|
|
*barf*
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Having dozens of DLLs, just to break out the code into bite-sized pieces seems pointless to me - but if there is a "real" need for such then OK.
For example: Prior to .NET I was working on a C++ project that ran data-center automation 24/7 and was not supposed to stop, even for updates.
I designed a system where there was a "stub" program, that didn't change, but all the functionality was spread across several DLLs. These DLLs were real Dynamic Link Libraries in that they were dynamically loaded by the "stub". When some functionality was added, updated or corrected, the appropriate DLL was put in a specific directory and the stub would detect it, unload the old DLL and load in the new one without stopping the main process. With built-in precautions and locks around certain functionality this worked beautifully all the time. Only very rarely did we have to stop and restart the whole thing. Most of the DLLs were eventually actually loaded by other DLLs in a hierarchy and the "core" DLLs were hardly ever updated.
The number of DLLs started at three but eventually grew to, I think, eight or possibly nine as we extended the functionality adding voice interface and telephone alerting and remote support, etc.
We had groups of machines running a huge data center (they replaced the operator's console) with one of those running continuously for nearly four years, non-stop. For some reason back then the PCs didn't have to be "updated" or "patched" every other Tuesday just to keep working - so the Windows NT 3.51 and Window NT 4.0 machines just kept running, running, running...
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
I've run into similar situations. I usually write them like a "microkernel" - and make a message/signal passing system usually on top of the OS's mechanisms (GUIless window handles in windows or signals in unix)
the microkernel is basically just a router/dispatcher and is the only thing that is always loaded. sometimes i make them hotpatchable via bootstrap.
but then yeah, the rest of it is in separate binaries.
i used to do a lot of real time embedded for critical systems and so this came up a lot.
but you can't write realtime code in .NET anyway. =)
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Sometimes it is possible to merge these little f*ckers into one DLL or EXE with the help of ILMerge or Fody Costura.
I also found this useful in case of conflicts with projects using different versions of NewtonSoft.Json.dll 
|
|
|
|
|
makes one wonder how many projects would be this way if Microsoft had thought to make static linking a first class function of .NET
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
maybe some manager decided to separate it into lots of DLL's by lots of different programmers so no single person had all the pieces to steal the application.
in real life some companies do do this with regard to part manufacturing in China
...often not realizing many of those companies actually sub the work (or are commission agents) for the same large [actual] contract manufacturer
Message Signature
(Click to edit ->)
|
|
|
|
|
seems silly in .NET's case due to perfect type info / reverse engineering.
An obsfucator won't slow down someone who worked on the project much, I think.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
shhhhh, don' tell the managers
Message Signature
(Click to edit ->)
|
|
|
|
|
As a rule, I tell managers as little as I absolutely have to. It's better for everyone that way.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
codewitch honey crisis wrote: I see I'm not alone in this sentiment.
Too bad that this is not a question of democracy. 
codewitch honey crisis wrote: think context is important
A pearl of wisdom. What will come next? Water is wet?
codewitch honey crisis wrote: there's a time and a place for lots of DLLs (like server code) and times when it's overdone
ANd yet another pearl of wisdom! As if there was anything that will not become problematic if it's misused.
codewitch honey crisis wrote: I'll cede that if you will.
Too gracious.
If you have several products, it might be wise to have shared components, so that all the projects profit from matured and well maintained code. The result is a pile of DLLs, but that may be a sign of quality and nothing bad at all. No matter where it appears, server or not.
And now follow me to the Emperor. He will show you the Dark Side.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
