Gripe: No, you can keep your 60 tiny DLLs. I'll find another way.
-
codewitch honey crisis wrote:
In the OP I'm talking about a 10th of that per DLL. I find it excessive. You (presumably?) do not. To each their own.
I simply don't care as long as these assemblies contain what is needed, no more or less. Bundling things without need reduces your flexibility, which may get you in trouble. On the other hand it does not offer any real benefit other than looking nicer.
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.
in cases like one click deployment and small self installing packages (like utorrent is or used to be?) it's nice to not have to lug around DLLs. it's also easier to write installers and maintain them when you don't have (like another commenter lamented) 2000 DLLs in a project. Even 60 is a chore. Better to keep it to a few, maybe a dozen for middling-to-large applications. Server code is a different story for a number of reasons.
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 you saw my projects you couldn't level the criticism of them you're leveling.
That would be nice.
codewitch honey crisis wrote:
There are ways to address redundancy that don't lead to overfactoring.
Yes, but redundancy is the only way out of a circular reference. No compiler plays along with a circular reference for good reasons and if you mix different purposes into one stew in a single assembly, circular references are only one step away if you ever need to separate these concerns afterwards. You are on the safe side when you do that in the first place.
codewitch honey crisis wrote:
But then I grew up on C++, and the days where programs still had reasonable install bases on them.
And I started out on machine code and hex keypads. The scope and ambition of the code I worked on since then has grown constantly. And it's certainly not true that we had no use for the #include preprocessor directive in C or C++. With all benefits and consequences, like the Win32 DLL hell.
codewitch honey crisis wrote:
My DLLs average about 60k to 150k in .NET. Not 16. And I don't have those problems you mention.
Good to hear, but size is still irrelevant. More interesting is if an assembly contains all that is needed, no less and no more. You can't measure adequacy in bytes.
codewitch honey crisis wrote:
But then, I also use some tricks to keep the source manageable and the maintenance down.
Some people prefer to call that architecture. Tricks often are more trouble than they are worth.
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.
I'm giving you broad strokes as to how much code is in one. period. Not intended to be a metric of functionality but simply to give an idea of the ballpark of how much code i tend to put into one. Includes are fine if you use them appropriately. Great in some cases.
Some people prefer to call that architecture. Tricks often are more trouble than they are worth
And how do you know what I mean by tricks? all it is is a shorter way to type technique. Technique is not more trouble than it's worth. I think we're done here. Like I said, we'll have to agree to disagree and we've both said what we needed to say. In any case, I have stuff to work on, I'm not looking to argue endlessly about this.
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.
-
in cases like one click deployment and small self installing packages (like utorrent is or used to be?) it's nice to not have to lug around DLLs. it's also easier to write installers and maintain them when you don't have (like another commenter lamented) 2000 DLLs in a project. Even 60 is a chore. Better to keep it to a few, maybe a dozen for middling-to-large applications. Server code is a different story for a number of reasons.
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:
Server code is a different story for a number of reasons.
Why, actually? A good layered architecture always is a good idea, no matter what it's for or where you want to deploy it. In a way, layers are just another way to separate concerns.
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:
Server code is a different story for a number of reasons.
Why, actually? A good layered architecture always is a good idea, no matter what it's for or where you want to deploy it. In a way, layers are just another way to separate concerns.
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.
because server code is more liable to need hotfixing and this is easier with highly segregated DLL code. And you can architect things and factor them out without putting everything in separate DLLs. because server code doesn't really need things like click-deploy - server code usually has complex deployment in place anyway, so the infrastructure for supporting all those files is already in place. because server code needs to be updated without bringing the server down, which isn't generally an issue in user applications. Classes are for layering. You don't always need DLLs for that.
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'm giving you broad strokes as to how much code is in one. period. Not intended to be a metric of functionality but simply to give an idea of the ballpark of how much code i tend to put into one. Includes are fine if you use them appropriately. Great in some cases.
Some people prefer to call that architecture. Tricks often are more trouble than they are worth
And how do you know what I mean by tricks? all it is is a shorter way to type technique. Technique is not more trouble than it's worth. I think we're done here. Like I said, we'll have to agree to disagree and we've both said what we needed to say. In any case, I have stuff to work on, I'm not looking to argue endlessly about this.
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.
No need to get angry. Anyway, over here it's already getting late and almost time for bed. The planet is not flat after all. How about a prayer at bedtime:
Quote:
God, grant me the serenity to accept the things I cannot change, courage to change the things I can, And wisdom to know the difference.
Good night!
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.
-
No need to get angry. Anyway, over here it's already getting late and almost time for bed. The planet is not flat after all. How about a prayer at bedtime:
Quote:
God, grant me the serenity to accept the things I cannot change, courage to change the things I can, And wisdom to know the difference.
Good night!
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.
I'm not angry. I'm just done. Good night!
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.
Try front-end development.
npm install whateverYour npm folder now has 12641 files for a total of 2.4 MB.Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
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.
Are you trying to reference a ".NET Standard 2" library from a project targetting a .NET Framework version earlier than 4.7.2? That'll give you lots of tiny support assemblies to provide the "standard" features that weren't available in earlier versions. Changing the project to target 4.7.2 or later should get rid of them. Using .NET Standard with Full Framework .NET - Rick Strahl's Web Log[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
"These people looked deep within my soul and assigned me a number based on the order in which I joined" - Homer
-
Are you trying to reference a ".NET Standard 2" library from a project targetting a .NET Framework version earlier than 4.7.2? That'll give you lots of tiny support assemblies to provide the "standard" features that weren't available in earlier versions. Changing the project to target 4.7.2 or later should get rid of them. Using .NET Standard with Full Framework .NET - Rick Strahl's Web Log[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
no, i'm talking about opening a VS solution and having 60 projects in it.
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.
I'm for one or two bigger Dll's, especially if i have multiple exe's accessing the same classes. i don't see the point of beaking a ptoject into tiny pieces, especially when they have to work with each other. I'm still of the mindset to keep my code as small as possible because of many years of updating customer software over Dialup. if the whole compiled project got over 2mb i was doing something wrong and needed to refactor.
-
I'm for one or two bigger Dll's, especially if i have multiple exe's accessing the same classes. i don't see the point of beaking a ptoject into tiny pieces, especially when they have to work with each other. I'm still of the mindset to keep my code as small as possible because of many years of updating customer software over Dialup. if the whole compiled project got over 2mb i was doing something wrong and needed to refactor.
All of this I agree with.
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.
I've never used a DLL in a .NET ptrogram, because I hate dealing with the problems they create. I statically link the libraries I need to access and make the installation process clean and don't worry about DLL conflicts. That's a lesson I learn back with DOS.
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
-
I've never used a DLL in a .NET ptrogram, because I hate dealing with the problems they create. I statically link the libraries I need to access and make the installation process clean and don't worry about DLL conflicts. That's a lesson I learn back with DOS.
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
.NET doesn't suffer from most of those old problems with DLL versioning. It is an extra dependency to drag around as part of the install base though so i feel you. There is certainly a place for simple install bases, and i think it applies to smallish user applications and services. sometimes i get *really* extreme and make small .net services and the like "self installing" mysvc /install mysvc /uninstall then i don't even have an installer. =P
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.
-
.NET doesn't suffer from most of those old problems with DLL versioning. It is an extra dependency to drag around as part of the install base though so i feel you. There is certainly a place for simple install bases, and i think it applies to smallish user applications and services. sometimes i get *really* extreme and make small .net services and the like "self installing" mysvc /install mysvc /uninstall then i don't even have an installer. =P
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:
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.
Yeah, I know what you mean. I'm the only kid on the block to have a PhD and my wife still insiststhat I 'm useless. I saw an ad the other day for some medication and it said if you experience rapid heartbeat irregular breathing and confusion, consult you doctor right away. I experienced that once, but I married her and the confusion got worse, so the doctor may have been a better choice.
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
-
.NET doesn't suffer from most of those old problems with DLL versioning. It is an extra dependency to drag around as part of the install base though so i feel you. There is certainly a place for simple install bases, and i think it applies to smallish user applications and services. sometimes i get *really* extreme and make small .net services and the like "self installing" mysvc /install mysvc /uninstall then i don't even have an installer. =P
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.
This may be starting to get into programming, but I'll ask for forgiveness rather than permission: How do you make an application self installing? I used to make setup projects in VS2008, but the newer versions of VS don't have that option.
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
-
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.
Pretty sure you were under a rock or something. Most modern code is client/server and needs a ton of dependencies, which can't be bundled into a single DLL due to license problems. With that in mind, .NET begs separation of concerns, so during compilation, regardless of the type of code have, you end up with a gazillion Namespaced DLLs. It would be wiser to have in Windows what NeXT, macOS and iOS started in 1988 and create single folder (*.app) masked as a self contained application where all *.so or *.dll would reside and any foreign code would simply be `symlinked` from source at install time. But that ship has sailed and not even UWP apps do that successfully. So with that in mind, if you want clean code you must go the macOS route, else you'll notice that any #WinUI or Win32 code gets filled easily with DLL. So
¯\_(ツ)_/¯
Keep Calm and Keep Coding
-
This may be starting to get into programming, but I'll ask for forgiveness rather than permission: How do you make an application self installing? I used to make setup projects in VS2008, but the newer versions of VS don't have that option.
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
It depends on the app but what I usually do is just build my own tiny installer that writes the registry or as is usually the case, runs com registration and installs itself as a service using the service API. The other option is to use a third party tool (is WIX still around?) to build an installer, embed that as a resource, extract it, run it as a silent install - this will give you all of the fluff of an MSI install - including a program entry in "Add/Remove programs" but that isn't that necessary for tiny apps.
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.
-
Pretty sure you were under a rock or something. Most modern code is client/server and needs a ton of dependencies, which can't be bundled into a single DLL due to license problems. With that in mind, .NET begs separation of concerns, so during compilation, regardless of the type of code have, you end up with a gazillion Namespaced DLLs. It would be wiser to have in Windows what NeXT, macOS and iOS started in 1988 and create single folder (*.app) masked as a self contained application where all *.so or *.dll would reside and any foreign code would simply be `symlinked` from source at install time. But that ship has sailed and not even UWP apps do that successfully. So with that in mind, if you want clean code you must go the macOS route, else you'll notice that any #WinUI or Win32 code gets filled easily with DLL. So
¯\_(ツ)_/¯
Keep Calm and Keep Coding
I haven't been living under a rock. I just don't do a lot of work with 3rd party components most of the time, and the big offenders like MonoTorrent don't have any 3rd party dependencies but still have like 40-60 projects in them. <-- those are what I'm mainly griping about. You make an excellent point about macos and while I wouldn't necessarily package my filesystem/shell that way** it's a good idea. ** honestly, I'd just make "filesystem extensions" that allow you to traverse compound files like tars and zips and other containers like part of the filesystem - and supporting native FS calls. That way you can just dump everything in it's own "subfilesystem" hive and have that mapped to a tar, or even a flat bin file with an OS FAT header on it.
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.
We focus heavily on code reuse, so DLL boundaries are focused on assembly dependencies, not on related tasks or something. For example, we have a large C# DLL called Core that has no third-party dependencies, so a bunch of stuff is lumped together that are not related. On the other hand, we wrap a third-party device DLL, so that wrapper is in a DLL by itself due to the extra assembly dependency. The result is that we have a enough DLLs to allow for DLL-boundary code reuse, but we do not further subdivide them based on related source code. The compromise prevents us from having too many DLLs. We have about 40, each with different assembly dependencies.
-
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.
It was a good idea back when bandwidth was not a generous as it is now. You could update only the small DLLs or small EXE that changed during minor version changes. That made updates quicker and easier.
