|
That's assuming he will miss piggy-backing on a big bird or some other animal you grouch.
|
|
|
|
|
Maybe he just doesn't want to go on a summer holiday?
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
|
I saw him do it...he was Gonzo quickly.
|
|
|
|
|
Sounds like rather Fozzie logic to me.
... such stuff as dreams are made on
|
|
|
|
|
Just trying to get to Sesame Street.
Hogan
|
|
|
|
|
|
what if it is a female frog, or does the question only relate to male frogs?
|
|
|
|
|
List of famous female frogs, please .....
Uh-huh, thought so!
I am not a number. I am a ... no, wait!
|
|
|
|
|
|
MarcusCole092076 wrote: Pufnstuf
Indeed they were!  I really didn't get how 'trippy' it was at the time.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
Well, if he makes a green splat at the bottom, don't ask me to muppet up.
|
|
|
|
|
Actually are you sure he (it?) is not a lemming?
|
|
|
|
|
Beats the cr@p out of being eaten by a Frenchman.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
|
This discussion came up at work today, with pretty much everyone falling on the side of using multiple assemblies, but with no viable reason for doing it that way, and most of the time saying, "because I've always done it that way".
Beyond utility methods or object extensions living in assemblies that could be added as a reference and that could be used throughout other solutions, what's the point of creating multiple assemblies when a thoughtful arrangement of folders in a single-project solution would be perfectly adequate? It even appears as if Microsoft intended for it to be this way.
I suppose an argument could be made in a team environment to more clearly separate concerns and ease source control issues, but even that's kinda flimsy at the heart of it.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
modified 14-Jun-16 9:03am.
|
|
|
|
|
Used carefully, internal (Friend) classes, methods and so on can be a useful tool for controlling who uses what and that capability is lost to you if you have everything lumped into one large assembly.
|
|
|
|
|
I think this is more of a code organization discussion rather than one of accessibility.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
In that case, so long as each project compiles to its own assembly, there is no problem I can see having all the projects in one solution in a subfolder per assembly basis.
|
|
|
|
|
That's what protected and private are for.
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
It depends what you're doing really. A stand alone application/library might be fine in a single assembly, but a solution may have multiple projects, a desktop app, a web app etc. that share the same common components [data access for example]. In which case it's easier if everything is separate and updates to individual components can be released without having to reinstall whole applications.
|
|
|
|
|
N-tier architecture? duh.
Presentation layer (desktop,web, mobile, etc.)
Business layer
Data layer
Domain - models project.
etc....
WCF services
Web API
blah, blah, blah
|
|
|
|
|
I have the same experience as well, developers advocating multiple assemblies, mostly "just because". I haven't really heard a compelling argument. Separation of concern should be done at class level, and beyond that separate assemblies rarely (if ever) add anything to it.
On the other hand I had to deal with multiple issues because of this. One client had a solution so split up, when built it would take up 1 GB of disk space because projects referenced other projects, and every time the dlls would get copied to the output directory, some dlls duplicated 20+ times. And if this does not sound bad enough, it wasn't some huge back-end transactional processing whatever system. It was a web site with around 25 pages (I wish I was exaggerating).
Second issue I've noticed that it's a nightmare for dealing with circular references, because there will always be at least 1 instance of this happening, and the more dlls the more likely. One company solved this by making every dll a NuGet package as well. It was a PITA to build, as you had to build project A, publish it to the feed, update for project B and then build that. But hey, at least no one had to do care where to put what...
Obviously not saying multiple assemblies are a bad thing per se, but in my experience they are used lot more then they should be.
|
|
|
|
|
If you have a circular reference that means you're doing something you shouldn't be doing. 
|
|
|
|
|
I'm with you, I'm just saying it will come up eventually when extending existing software. Or rather, you will have situations where you would have those, so you just have to refactor. Or do that horrible NuGet stuff...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
