7 ms·

You've obviously never suffered a large project. Crashes, memory gobbling, random debugger failures, glacial speed, lag, project configuration corruption, UI gl

by meaty 14y ago

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.

gfody 14y ago
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?
- meaty 14y ago
  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.
ComputerGuru 14y ago
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.
- tucaz 14y ago
  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.
  - wcoenen 14y ago
    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".
    - tucaz 14y ago
      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.
      - beagle3 14y ago
        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.
      - majc2 14y ago
        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.
  - elorant 14y ago
    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.
- kirse 14y ago
  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.
  - deleted 14y ago
    [deleted]
  - PommeDeTerre 14y ago
    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.
- LargeWu 14y ago
  If a single project is several hundred million lines of code, VS probably isn't the problem.
- jongalloway2 14y ago
  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.
- yannickt 14y ago
  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.
  - yannickt 14y ago
    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.
  - yannickt 14y ago
    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-visual-studio-2012-feedback-tool-a-better-way-to-submit-bugs.aspx http://blogs.msdn.com/b/visualstudio/archive/2012/06/20/the-...
- blablabla123 14y ago
  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.
corresation 14y ago
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).

by meaty 14y ago

gfody 14y ago

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?

meaty 14y ago
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.

ComputerGuru 14y ago

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.

tucaz 14y ago
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.
- wcoenen 14y ago
  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".
  - tucaz 14y ago
    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.
    - beagle3 14y ago
      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.
    - majc2 14y ago
      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.
- elorant 14y ago
  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.
kirse 14y ago
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.
- deleted 14y ago
  [deleted]
- PommeDeTerre 14y ago
  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.
LargeWu 14y ago
If a single project is several hundred million lines of code, VS probably isn't the problem.
jongalloway2 14y ago
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.
yannickt 14y ago
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.
- yannickt 14y ago
  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.
- yannickt 14y ago
  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-visual-studio-2012-feedback-tool-a-better-way-to-submit-bugs.aspx http://blogs.msdn.com/b/visualstudio/archive/2012/06/20/the-...
blablabla123 14y ago
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.

corresation 14y ago

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