Hacker News Reader

Comment by meaty | Hacker News Reader

You've obviously never suffered a large project. Crashes, memory gobbling, random debugger failures, glacial speed, lag, project configuration corruption, UI glitches, refusing to load projects, half complete refactoring operations, search/replace just stops, having to reset environment at least once a day, grey screen of death.

And that's just the IDE. CLR is the only framework and language combo I've used which will quite happily just stop working with no human intervention one day.

It's a bag of shit for me and I resent using it.

For ref, I've been building software on windows since 1994 from win32 to wpf to asp.net to mvc to WCF.

The only positive thing I can say is the money is good, but it's danger money.

View on HN

Yes, agreed (having worked on middlish-big projects with maybe 40 VS projects for each solution, 45+ minute re-compile times (not from scratch) on the latest gen CPUs, etc) with several hundred million LoC but believe me, if you think that's bad, you don't want to see Eclipse/NetBeans/XCode/etc. with a project a thousandth of that size.

I know nothing about nothing, but having that many projects under the same solution its the biggest clue that you are doing something very wrong.

Even if you have a reason to have 40 projects in what should looks like one solution you can still create various solutions files with just the subset of projects you need. No one works on 40 projects at the same time.

Half of those projects could be class libraries. You can't put those in different solutions cause you miss the whole point of having everything tied up.

We don't have hundreds of millions LoC, but we have a couple of million. We solve the problem you are describing with svn:externals, pulling in the DLL/PDB from other project/solutions as needed on svn up.

I agree it's not as comfy as having everything in one big solution, but being able to count your compile time in seconds as opposed to minutes makes it worthwhile.

It's sadly far too common for .NET developers to carve up their solutions into far more projects than are necessary. This can seriously slow down compilation times.

Actually if you are changing a dependency right at the bottom of the chain, it makes things much faster as each compilation unit (assembly) is less likely to be coupled to the changed code.

Large assemblies are the enemy of compilation time as you can't partially compile them (like you can with java individual classes).

Incremental compiler in C#: http://msdn.microsoft.com/en-us/library/aa691231(v=vs.71).as...

That was in 1.0 and 1.1. Gone in 2.0+

http://msdn.microsoft.com/en-us/library/ms379563%28v=vs.80%2...

Yes but that's not the case if you're changing a dependency in the middle of the chain, as is more commonly the case.

Additionally, as far as I can tell, the main thing that slows compilation down isn't so much the actual compilation step as loading in and copying all the project references. Visual Studio does this separately, from scratch, for every project that you rebuild, since each project compilation runs in a separate csc.exe process.

Quote from Jeremy Miller: "I took 56 projects one time and consolidated them down to 10-12 and cut the compile time from 4 minutes to 20 seconds with the same LOC" (http://codebetter.com/jeremymiller/2008/09/30/separate-assem...)

It depends on the size of the project. Our dependencies compile into 130Mb of DLLs excluding all external references.

That's expensive to build.

In that case it's probably sensible to break it up not only into separate projects but separate solutions too.

What bugs me is when relatively small solutions are broken up into large numbers of projects. Very often it's done for no reason whatsoever other than aesthetics. They're often divided up "against the grain" too, putting every layer of your application (presentation layer, business layer, repository, domain model, services, interfaces etc) into a separate project, with the result that a single task requires you to make changes to several different projects.

The general rule that should be followed here is the Common Closure Principle: classes that change together should be packaged together.

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".

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.

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.

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.

We used to use several different solutions with subsets of the projects, now though I use the solution load manager extension, http://visualstudiogallery.msdn.microsoft.com/66350dbe-ed01-... which brings down load times significantly. It basically lets you specify how projects should be loaded, so most can be loaded on demand. We have ~150 projects in total, ~10 million LOC, and VS handles it almost as well as a small solution.

Slightly curious, what kind of projects were you working on that are "several hundred million LoC"... wouldn't 45-minutes be reasonable for that many lines of code?

I ask because I've never even come close to touching a project with that many SLOC and I was also under the impression that most modern operating systems are barely fitting into 100million+ LoC category, correct? This is your chance to redefine my perspective on "big project" haha.

A lot of the code may be automatically generated.

Some C# developers use T4 to generate data access code, for instance. This can amount to several hundred thousand lines of code for a moderately sized database. If there are several large databases being accessed, like is often the case in reality, then I could easily see there being millions of lines of automatically generated code in a single project.

If a single project is several hundred million lines of code, VS probably isn't the problem.

I think when you hit several hundred million lines of code in a solution, a governor kicks in to give you more time to think about just what the hell you're doing.

I'm pretty sure I've read on an msdn blog that visual studio was 100 million loc total. I would be very curious to know what kind of projects you're working on.

For what it's worth, I'm currently working on a number of C/C++ projects that amount to ~15MLOC. Visual Studio handles that load just fine.

My 100 MLOC figure is incorrect. The blog post actually states: "With upwards of 50 million lines of code, broad changes to Visual Studio can take some time to fully incorporate."

Here's the link: http://blogs.msdn.com/b/visualstudio/archive/2012/06/20/the-...

Eclipse is fast, but it needs to be configured well and run on a decent system. I guess the same is true for VS. After all both wouldn't be so popular if they wouldn't scale.

This is one of those anecdotes that just pollutes discussions, allowing people to cheer on their biases. My anecdote is that Visual Studio deals with very, very large projects with gusto (albeit far below the absurd "hundreds of millions of lines of code" scenario described by someone else, which if in one solution borders on insane). The CLR has worked ridiculously well for years on end with nary a hiccup in sight. And so on.

Visual Studio isn't perfect, nor is any IDE (Eclipse...xcode...Geez, turn on the coffee machine because we'll be spilling complaints all night long).

sounds like you should get a new computer. 1994's a long time to go without at least a fresh install of windows - have you tried defragmenting your hard drive?

I've got a nice Dell Precision dual 4 core 2.8ghz xeon, 32gb of ecc ram, 500gb sas 15k RAID, Samsung 840 pro scratch drive and quardro card. What am I doing to deserve this pain?

My 5 year old Lenovo t61 is fine for ALL other tasks in all other languages.

Reply on news.ycombinator.com