10 ms·

I just wrote a comment on the other post about this. I wonder how this decision was made _behind the scenes_. Either some negotiation happened and the Visual

I just wrote a comment on the other post about this. I wonder how this decision was made _behind the scenes_. Either some negotiation happened and the Visual Studio team got some concessions (smaller target?) or it was mandated from the top. Both alternatives do not bode well for the VS team.

aliswe 5y ago
in large organizations like these there will always be desync issues, though.
ethbr0 5y ago
At this point, VS needs to be put under VSC management. You saw the same crap with Office vs everything new.
- blibble 5y ago
  yep, modern Visual Studio is a terrible experience end-to-end it takes at least 3 minutes to start, the UI designer takes 30+ seconds to appear, and starting your process for debugging takes 10+ seconds every single autocomplete takes a few seconds to appear even opening a 100 line .c file takes 10+ seconds, and they KNOW its bad because it pops up a dialog with a progress bar! this is all on a azure "cloud" instance with 8 cores, 64gb of ram and SSD, with a clean install every 2 weeks not to mention nearly all of the dialogs are as awful and exactly the same as they were in VS6 (e.g. run configurations) and it's super expensive meanwhile VSC is snappy and free, and the JetBrains IDEs of 2011 run rings round it
  - tester756 5y ago
    I'm using VS almost everyday, sometimes even 2 or 3 instances at the time and it does not reflect my experience, but the difference is >even opening a 100 line .c that I'm using it for C#.
  - mrec 5y ago
    I haven't used VS in years, but the only time I've seen Windows crash to BIOS in the last two decades was during a VS install.
  - ComputerGuru 5y ago
    What’s extensions do you have installed? VS 2019 significantly fixed performance issues, and I work with both C++ and C# projects much bigger than a few hundred lines of code. Debugging UWP and ASP.NET Core is a lot slower than debugging regular old WPF or SWF but that’s because of all the bloat during the deployment step. If you have VisualAssist or Resharper installed, disable them and see the difference.
    - blibble 5y ago
      none, clean installation every 2 weeks (note I said a file with a hundred lines of code, not project)
      - ComputerGuru 5y ago
        Yeah, I have no problem with cs or cpp files thousands of lines long. Granted, I'm loading the project from an NVMe disk, but I just don't see what you're running into.
  - thrower123 5y ago
    You can trace a lot of these problems to their bone-headed decision about a decade ago where they refused to see where things were going and kept rationalizing not moving to 64-bits. I have some moderately sized solutions that take forever to open and chug to a halt and start paging like crazy with unresponsive UI if I don't disable all the code inspections and Intellisense. This is on a brand-new i7 with 32GB of RAM and a NVME SSD. It pegs itself at that 32-bit process memory limit and thrashes. It's worse if it is a modern web app with a bunch of JS involved. And so I've used Rider almost exclusively for the past fifteen months or so...
    - rk06 5y ago
      FWIW, vs2022 is 64bit.
      - foepys 5y ago
        And they promptly shot themselves in the foot with it as you now need 64bit components for their form designers, even if you exclusively build 32bit apps. If you maintain an application with legacy form components that are only available in 32bit, you now need to continue using VS2019. Granted, who builds 32bit in year 2022 but VS claims to support 32bit, which it actually doesn't fully. There is still a chance that they will fix this before release but I highly doubt it.
        liversage 5y ago
        Perhaps that's one of the reasons they have didn't switch to 64 bits earlier? If the IDE is a 64 bit process it can only render external components at design time if they are 64 bits. To be able to render 32 bit components at design time they would need to be hosted in another 32 bit process. I can see how that feature would be complicated and expensive to develop.
  - ziml77 5y ago
    Are you loading your projects from a network mount? Because the timings you're giving don't make any sense for those specs. I could believe it if the files aren't local though since VS does a lot of disk IO in the solution directory.
    - foepys 5y ago
      A company I worked for used network shares for years for C# projects. It was a tad bit slower loading the solution but if you didn't know, you'd never notice.
  - rafaelvasco 5y ago
    VS2022 takes ~5 seconds to start. Auto complete is milliseconds etc. Starting anything is a couple seconds max. There's something very wrong with your machine. VS2022 is an amazing experience end-to-end.
    - blibble 5y ago
      it's not my machine as I stated, it's a high end VM on Azure, using the official MS OS image and it does a clean install every 2 weeks (completely clean registry+userprofile), so there's no inherited crap/extensions meanwhile VScode and jetbrains IDEs on the same VM are perfectly usable
  - Yuioup 5y ago
    Your boss really should be upgrading your laptop.
  - DeathArrow 5y ago
    Not my experience. And I have multiple instances of VS open each time. The only times it can become less responsive is due to extensions such as ReSharper.
M2Ys4U 5y ago
The Verge has an article about this.[0] >The Verge understands that the decision to remove the functionality from .NET 6 was made by Julia Liuson, the head of Microsoft’s developer division. Sources describe the move as a business-led decision, and it’s clear the company thought it would fly under the radar and not generate a backlash. Engineers at Microsoft that have worked on .NET for years with the open source community feel betrayed and fear the decision will have lasting effects on Microsoft’s open source efforts. [0] https://www.theverge.com/2021/10/22/22740701/microsoft-dotnet-hot-reload-removal-decision-open-source https://www.theverge.com/2021/10/22/22740701/microsoft-dotne...
- stefan_ 5y ago
  This is the kind of boneheaded, "my division above all" move that should see someone removed off any product decisions whatsoever. Reminds me of the people at Android that keep pushing big carrier SMS group chat protocols, where everyone can tell from miles afar they are just a blind caterpillar sensing their way along some local optimum gradient descent in whatever mismatched incentive hell their big corp job has landed them.
- whoisthemachine 5y ago
  While I'm sure the business drove the decision, some developer had to make the pull request, no? What I wonder is whether a "lose your job if you don't do as I wish" gun was stuck to a developer's head, or did they find the right developer with the right permissions to push this change through in spite of resistance? The former option gives me shudders, while the latter saddens me. EDIT: grammar
  - skohan 5y ago
    Or the manager wrote a ticket to make the change, and the developer just did it as part of their job with no fanfare or minimal resistance seems like the most likely scenario
  - DeathArrow 5y ago
    Usually they open a ticket, some poor guy has to execute it unless he doesn't want to lose his job.

aliswe 5y ago

in large organizations like these there will always be desync issues, though.

ethbr0 5y ago

At this point, VS needs to be put under VSC management. You saw the same crap with Office vs everything new.

blibble 5y ago
yep, modern Visual Studio is a terrible experience end-to-end it takes at least 3 minutes to start, the UI designer takes 30+ seconds to appear, and starting your process for debugging takes 10+ seconds every single autocomplete takes a few seconds to appear even opening a 100 line .c file takes 10+ seconds, and they KNOW its bad because it pops up a dialog with a progress bar! this is all on a azure "cloud" instance with 8 cores, 64gb of ram and SSD, with a clean install every 2 weeks not to mention nearly all of the dialogs are as awful and exactly the same as they were in VS6 (e.g. run configurations) and it's super expensive meanwhile VSC is snappy and free, and the JetBrains IDEs of 2011 run rings round it
- tester756 5y ago
  I'm using VS almost everyday, sometimes even 2 or 3 instances at the time and it does not reflect my experience, but the difference is >even opening a 100 line .c that I'm using it for C#.
- mrec 5y ago
  I haven't used VS in years, but the only time I've seen Windows crash to BIOS in the last two decades was during a VS install.
- ComputerGuru 5y ago
  What’s extensions do you have installed? VS 2019 significantly fixed performance issues, and I work with both C++ and C# projects much bigger than a few hundred lines of code. Debugging UWP and ASP.NET Core is a lot slower than debugging regular old WPF or SWF but that’s because of all the bloat during the deployment step. If you have VisualAssist or Resharper installed, disable them and see the difference.
  - blibble 5y ago
    none, clean installation every 2 weeks (note I said a file with a hundred lines of code, not project)
    - ComputerGuru 5y ago
      Yeah, I have no problem with cs or cpp files thousands of lines long. Granted, I'm loading the project from an NVMe disk, but I just don't see what you're running into.
- thrower123 5y ago
  You can trace a lot of these problems to their bone-headed decision about a decade ago where they refused to see where things were going and kept rationalizing not moving to 64-bits. I have some moderately sized solutions that take forever to open and chug to a halt and start paging like crazy with unresponsive UI if I don't disable all the code inspections and Intellisense. This is on a brand-new i7 with 32GB of RAM and a NVME SSD. It pegs itself at that 32-bit process memory limit and thrashes. It's worse if it is a modern web app with a bunch of JS involved. And so I've used Rider almost exclusively for the past fifteen months or so...
  - rk06 5y ago
    FWIW, vs2022 is 64bit.
    - foepys 5y ago
      And they promptly shot themselves in the foot with it as you now need 64bit components for their form designers, even if you exclusively build 32bit apps. If you maintain an application with legacy form components that are only available in 32bit, you now need to continue using VS2019. Granted, who builds 32bit in year 2022 but VS claims to support 32bit, which it actually doesn't fully. There is still a chance that they will fix this before release but I highly doubt it.
      - liversage 5y ago
        Perhaps that's one of the reasons they have didn't switch to 64 bits earlier? If the IDE is a 64 bit process it can only render external components at design time if they are 64 bits. To be able to render 32 bit components at design time they would need to be hosted in another 32 bit process. I can see how that feature would be complicated and expensive to develop.
- ziml77 5y ago
  Are you loading your projects from a network mount? Because the timings you're giving don't make any sense for those specs. I could believe it if the files aren't local though since VS does a lot of disk IO in the solution directory.
  - foepys 5y ago
    A company I worked for used network shares for years for C# projects. It was a tad bit slower loading the solution but if you didn't know, you'd never notice.
- rafaelvasco 5y ago
  VS2022 takes ~5 seconds to start. Auto complete is milliseconds etc. Starting anything is a couple seconds max. There's something very wrong with your machine. VS2022 is an amazing experience end-to-end.
  - blibble 5y ago
    it's not my machine as I stated, it's a high end VM on Azure, using the official MS OS image and it does a clean install every 2 weeks (completely clean registry+userprofile), so there's no inherited crap/extensions meanwhile VScode and jetbrains IDEs on the same VM are perfectly usable
- Yuioup 5y ago
  Your boss really should be upgrading your laptop.
- DeathArrow 5y ago
  Not my experience. And I have multiple instances of VS open each time. The only times it can become less responsive is due to extensions such as ReSharper.

M2Ys4U 5y ago

The Verge has an article about this.[0] >The Verge understands that the decision to remove the functionality from .NET 6 was made by Julia Liuson, the head of Microsoft’s developer division. Sources describe the move as a business-led decision, and it’s clear the company thought it would fly under the radar and not generate a backlash. Engineers at Microsoft that have worked on .NET for years with the open source community feel betrayed and fear the decision will have lasting effects on Microsoft’s open source efforts. [0] https://www.theverge.com/2021/10/22/22740701/microsoft-dotnet-hot-reload-removal-decision-open-source https://www.theverge.com/2021/10/22/22740701/microsoft-dotne...

stefan_ 5y ago
This is the kind of boneheaded, "my division above all" move that should see someone removed off any product decisions whatsoever. Reminds me of the people at Android that keep pushing big carrier SMS group chat protocols, where everyone can tell from miles afar they are just a blind caterpillar sensing their way along some local optimum gradient descent in whatever mismatched incentive hell their big corp job has landed them.
whoisthemachine 5y ago
While I'm sure the business drove the decision, some developer had to make the pull request, no? What I wonder is whether a "lose your job if you don't do as I wish" gun was stuck to a developer's head, or did they find the right developer with the right permissions to push this change through in spite of resistance? The former option gives me shudders, while the latter saddens me. EDIT: grammar
- skohan 5y ago
  Or the manager wrote a ticket to make the change, and the developer just did it as part of their job with no fanfare or minimal resistance seems like the most likely scenario
- DeathArrow 5y ago
  Usually they open a ticket, some poor guy has to execute it unless he doesn't want to lose his job.