News for hackers. Stuff that matters.
Re:Visual Studio and Team Foundation Server will have Git su... by wcoenen on Wednesday January 30, 2013 @06:13PM (#5142401)
We have a solution with more than 80 C# projects, and visual studio 2010/2012 handles it fine on modest hardware. I usually hit shift+F6 to build just the current project when I'm iterating on some change. This builds very fast because our individual libraries are small. It doesn't really feel "wrong".
Re:Visual Studio and Team Foundation Server will have Git su... by tucaz on Wednesday January 30, 2013 @09:37PM (#5143087)
Unless u have a very good reason to deploy and distribute 80 different DLLs it should feel wrong.

Many people think that In order to have a well layered and decoupled application you need to breakup every single piece in a separate project and that makes no sense. Thats what folders and namespaces are for.

Re:Visual Studio and Team Foundation Server will have Git su... by beagle3 on Wednesday January 30, 2013 @10:59PM (#5143368)
For C#, maybe (not enough experience, but I would be surprised if what you say is a good practice).

For C / C++: You do that with static libraries, not shared libraries, and that's the only sane way to work: Have all library projects part of your main workspace, so you can easily debug and fix stuff in them, yet manage them independently.

Re:Visual Studio and Team Foundation Server will have Git su... by majc2 on Thursday January 31, 2013 @06:56AM (#5144546)
For production/distribution you can always use a tool like ILMerge or SmartAssembly to merge dlls/exes together into something that makes sense for that particular distribution. I've had plenty of success with both tools.

Saying that, I do get what you're saying. Good practices can be taken to the extreme. Some approaches such as prism, take the idea of breaking the UI up into modules that can be registered with a shell - where on reflection, that type of flexibility is rarely going to be needed.