Gripe: No, you can keep your 60 tiny DLLs. I'll find another way.
-
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.
-
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.
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 ->)
-
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.
-
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 :suss: 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.
-
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 :suss: 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.
-
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.
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.
-
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.
If your DLLs are 16k is it worth sharing binaries rather than including a source file? Adding, as long as we're pointing out the obvious, no this isn't a democracy. Duh. I am emperor of my own projects, and my supers are emperors of my professional projects. Whomever the IP goes to is the arbiter of what it looks like. Water is wet. Note: I wasn't calling for a vote. Also obvious.
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.
-
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.
-
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.
-
If your DLLs are 16k is it worth sharing binaries rather than including a source file? Adding, as long as we're pointing out the obvious, no this isn't a democracy. Duh. I am emperor of my own projects, and my supers are emperors of my professional projects. Whomever the IP goes to is the arbiter of what it looks like. Water is wet. Note: I wasn't calling for a vote. Also obvious.
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:
If your DLLs are 16k is it worth sharing binaries rather than including a source file?
Size is irrelevant. The contents do. For example, I have a tiny DLL that only implements the baseclasses and interfaces for presenters and views for the MVP pattern. With this I was able to port an application from WebForms to WinForms, from there to WebForms and from there to my own UI that runs in a 3D engine under DirectX. All I had to do was to rewrite the views, which still were dependent on the presentation technology. That's all.
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.
-
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.
I have to disagree. A class, and therefore it's assembly, should do one thing and one thing only. if you're not segregating your functionality across multiple assemblies, then you probably have a few different problems. For one, It's harder to share code across apps. Consider a DAL assembly. it has one purpose - work on the DB. Multiple apps can use the same DAL assembly. Separating it into its own assembly mean greater code reuse. And, as others have said, it's a whole lot easier to update a small assembly than a large boated EXE.
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
-
codewitch honey crisis wrote:
If your DLLs are 16k is it worth sharing binaries rather than including a source file?
Size is irrelevant. The contents do. For example, I have a tiny DLL that only implements the baseclasses and interfaces for presenters and views for the MVP pattern. With this I was able to port an application from WebForms to WinForms, from there to WebForms and from there to my own UI that runs in a 3D engine under DirectX. All I had to do was to rewrite the views, which still were dependent on the presentation technology. That's all.
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.
interface DLLs are fair because of the way .NET works. In the general case however, we'll have to agree to disagree.
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.
-
I have to disagree. A class, and therefore it's assembly, should do one thing and one thing only. if you're not segregating your functionality across multiple assemblies, then you probably have a few different problems. For one, It's harder to share code across apps. Consider a DAL assembly. it has one purpose - work on the DB. Multiple apps can use the same DAL assembly. Separating it into its own assembly mean greater code reuse. And, as others have said, it's a whole lot easier to update a small assembly than a large boated EXE.
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
I don't believe every class deserves its own assembly. An assembly should perform a series of tightly related tasks, not a single task, but that's me.
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.
-
I don't believe every class deserves its own assembly. An assembly should perform a series of tightly related tasks, not a single task, but that's me.
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 don't believe every class deserves its own assembly.
I didn't say that. I said each class should do one thing. And each assembly should do one thing.
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
-
interface DLLs are fair because of the way .NET works. In the general case however, we'll have to agree to disagree.
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.
And what exactly is the general case we don't agree on?
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.
-
And what exactly is the general case we don't agree on?
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.
that an assembly should do just one thing
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.
-
I don't believe every class deserves its own assembly. An assembly should perform a series of tightly related tasks, not a single task, but that's me.
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 don't believe every class deserves its own assembly
Nor does he. He said that a class should only have a single responsibility and extended that to assemblies. I would also extend that to methods, which also should not be written to do everything and nothing at the same time. A class may have many methods, an assembly many classes, but they should share a common responsibility or you will very likely end up in dependency hell.
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.
-
codewitch honey crisis wrote:
I don't believe every class deserves its own assembly.
I didn't say that. I said each class should do one thing. And each assembly should do one thing.
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
which in .NET is basically saying one class deserves its own assembly. I don't know how else to read it at least.
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 don't believe every class deserves its own assembly
Nor does he. He said that a class should only have a single responsibility and extended that to assemblies. I would also extend that to methods, which also should not be written to do everything and nothing at the same time. A class may have many methods, an assembly many classes, but they should share a common responsibility or you will very likely end up in dependency hell.
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.
adding, on reflection i think we're arguing semantics. I'd say an assembly is for tightly coupled tasks. i agree with you about methods and classes. There are no global methods in .NET. So if we're talking a single task, per class, and a single class per assembly, under .NET that means one class per assembly, QED
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.
-
that an assembly should do just one thing
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.
Then you will sooner or later end up in dependency hell or have to live with redundancy. Both are not very pleasant and can make your projects unmaintainable. Is that really what you want to defend? Your right to shoot from your hip instead of putting some thought into your architecture? Or do you like to beat your code into submission. That may be fun for a while. Even quicker, which will make your bosses happy. At least until they discover that you have painted yourself into some corners which you can't get out of anymore.
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.
