3 ms·

So basically, if you need more than 4G it's your problem cause you're doing it wrong. What a horrible thing to say to your customers.

• gruez 6y ago
  the example in the 2022 announcement was a project with "1,600 projects and ~300k files", which maxes out at around 5GB. How many users actually experience this?
  • flukus 6y ago
    Sadly me and many others in large corporate environments. Not quite that bad but still pretty bad. My advice to people is to consolidate projects wherever possible, although you wouldn't know it seeing some project layouts you can still have separate namespaces and folders inside projects. I think many do this in the hope it will help build times but it does the opposite, msbuild is the slow part and csc (the c# compiler) is lightning fast, so make it do the heavy lifting.
    • tracker1 6y ago
      Yeah, if your projects are so tightly coupled that you have to work on them in the same Solution, then you may as well Join them most of the time. Another bit, I would generally have the Interfaces project include the client... so one DLL for other solutions to import from, and it doesn't really add much of anything to the Server implementation. That's just one example. Another is separating API controllers, DAL, BLL into separate Projects... there's rarely a practical reason for this, and in practice just adds indirection and complexity for very little real world value. But hey, "Enterprise" patterns and all.
• addicted 6y ago
  I think that’s an incorrect restatement of his view. I think what he is saying is that if Visual Studio is using too much memory then the problem is with visual studio and that it makes much more sense for the VS team to spend time and energy on retooling algorithms and data structures used in VS code to use up less memory than spending that time converting it to 64 bit.