Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Microsoft Software

Microsoft's Visual Studio 2022 Announced (microsoft.com) 121

Dave Knott writes: Microsoft has announced Visual Studio 2022, the next major revision of their flagship development IDE. A public beta will be arriving this summer. The most significant change, which has long been rumored, is that the entire application suite will now be 64-bit. Other major changes include:

* Performance improvements in the core debugger
* Support for .NET 6, which can be used to build web, client and mobile apps by both Windows and Mac developers, as well as improved support for developing Azure apps
* An update UI meant to reduce complexity and which will add integration with Accessibility Insights. Microsoft plans to update the icons and add support for Cascadia Code, a new fixed-width font for better readability
* Support for C++ 20 tooling. language standardization and Intellisense
* Integration of text chat into the Live Share collaboration feature
* Additional support for Git and GitHub
* Improved code search

This discussion has been archived. No new comments can be posted.

Microsoft's Visual Studio 2022 Announced

Comments Filter:
  • by petermp ( 891968 )
    .NET 6 will be a start - truly cross-platform, what Java was supposed to be ....
    • That's the source of nightmares, just imagining it near the servers.
    • Will .NET 6 ? Seems not. Sorry, what were you saying about truly cross platform?

      • ??? .NET 5 already runs on Linux, as did .NET Core before it.
        • Re: (Score:3, Insightful)

          by Viol8 ( 599362 )

          Only a subset and only on certain distros making it effectively useless. With Java you get everything.

          • by K. S. Kyosuke ( 729550 ) on Tuesday April 20, 2021 @07:46AM (#61293402)
            I've not yet encountered a distro that wouldn't run .NET Core. And as for "only a subset", I kind of haven't noticed that either (unless you're talking about stuff like .NET Core 1, for example). If you're talking about .NET APIs to certain Windows-specific features like Windows Forms, then of course those don't run on Linux, but that's technically not .NET code anyway, that's Win32 code interfaced to by .NET, so no reasonable person would expect it to run on Linux.
            • Re: (Score:3, Insightful)

              by EvilSS ( 557649 )

              I've not yet encountered a distro that wouldn't run .NET Core. And as for "only a subset", I kind of haven't noticed that either (unless you're talking about stuff like .NET Core 1, for example). If you're talking about .NET APIs to certain Windows-specific features like Windows Forms, then of course those don't run on Linux, but that's technically not .NET code anyway, that's Win32 code interfaced to by .NET, so no reasonable person would expect it to run on Linux.

              Hey do you actually work with this in real life? Get out of here with that shit! /. discussions are only for the ill informed to reinforce their own opinions of things they know nothing about. WTF were you thinking!?

            • by AmiMoJo ( 196126 ) on Tuesday April 20, 2021 @11:19AM (#61294074) Homepage Journal

              I wish WPF was cross platform, or that they would make something new that is similar. I don't bother too much with all the binding stuff but for doing quick, properly scaling and sizing UIs it's hard to beat.

              • There are C# bindings for Sciter, apparently.
              • The next gen XAML UI toolkit from Microsoft is called WinUI3, the push here is to replace both WPF and UWP with WinUI3. WinUI3 will work on both traditional desktop apps and Windows Store apps. The way it should have been, no wonder UWP didn't take off.

                Anyway, there's a 3rd party platform with Microsoft supporting them with some things, and supported by other things like the PRISM framework called Uno Platform [platform.uno]. This is pretty cool, it's compatible with WinUI3, in fact they unit test it with the unit tests t

                • by AmiMoJo ( 196126 )

                  Thanks, that looks quite interesting. I will give it a try next time.

                  • Here's an online playground [platform.uno] where you can test the Uno implementation of the WinUI3 controls online. Just type in WinUI3 XAML and it works. I was particularly impressed with the TreeView. It's not available from the drop down list, but just copy the TreeView example from this page [github.com] including the xml namespace declaration and you are good to go.
          • Thats pretty much any software on linux, some almighty neckbeard decided he didnt like some nitpicky detail and out it goes

          • I use a windows machine for work, but our CI pipelines are all running on Linux, and we deploy everything to Linux servers. At home I only use Linux machines and I've never had a problem developing or running dotnet core applications. I don't have experience with coding for android so I can't comment on that. Which distros specifically do you think have problems with it?
          • Comment removed based on user account deletion
            • And for GUIs there are tons of cross platform libraries available.
              Personally, i'm a fan of GTK#, but that's just because I'm used to running a GTK desktop.
    • by gtall ( 79522 )

      Ya, great, now we get MS Malware everywhere. Some win.

    • Me? I'd settle for a working intellisense instead of one that works for five minutes, stops working for ten minutes, starts working again, stops working until I do "rescan solution"... and this with code that isn't even being edited.

      Also one that doesn't think my perfect code needs red squiggles all over it. That would be good, too.

      And one that doesn't think half my variables are "ambiguous" and can go to the definition of a function instead of doing a plain-text search for it and giving 100 results for me

    • by jellomizer ( 103300 ) on Tuesday April 20, 2021 @10:09AM (#61293780)

      Except for the fact, that much of your existing code will need backward compatible libraries from .NET 2 and onward.

      Microsoft had a good idea with .NET but they implemented poorly, The speed of Java, with the platform independence of VB. This created problems with 32bit - 64bit conversion. Now with the problem that that x86 platform isn't nearly as dominate as it was back in 2001. Microsoft is just starting with .NET Core and 5 and 6 to be more cross platform is showing how much they had dropped the ball with the technology.

      Also today with modern systems, virtualization, and emulation is so common and proven technology, that cross platform development is becoming less of a big deal.

      That said with such things like Virtualization and emulation, I would like to see Server Side OS's to be much smaller, and just focused on running a small set of App's
      So a server that just handles Web Server, Database Server. This is more common with a Linux setup, but Windows is a bit heaver loaded.

      • by sosume ( 680416 )

        That said with such things like Virtualization and emulation, I would like to see Server Side OS's to be much smaller, and just focused on running a small set of App's
        So a server that just handles Web Server, Database Server. This is more common with a Linux setup, but Windows is a bit heaver loaded.

        Have you even tried Windows Server? You have the Web edition, the Datacenter edition, the Core edition (no GUI), and so on.

      • by Rinikusu ( 28164 )

        Kinda says something that these days when people think cross-platform development they grab.. node.js

        Need a website? Node.
        Need an editor? Node.
        Need a chat client? Node.
        Need to build an IoT device? Node.

        Fuck.

        I'm sure it really chaps MS's ass.

    • by DrXym ( 126579 )
      The ship already sailed on that one. If people aren't interested in Java then they're probably no more interested in .NET. Microsoft can thank themselves for that by only belatedly putting in some cross-platform support. I suppose it might be useful for app development assuming someone has an app they'd like to use on different phone OSes but not much outside of that.
      • by hjf ( 703092 )

        Or maybe people aren't interested in Java because it's a language that hasn't added features in like forever, and it's controlled by a troll corporation.

        Language- and framework-wise, .NET is what Java should have been. It has enough features and syntactic sugar that it makes it really nice to use. I really miss LINQ and typing when I'm doing JS nowadays. But I'm all JS now. Not going back to .NET.

        • by DrXym ( 126579 )
          Java has had features added to it but there is no doubting that Oracle have been a toxic influence. That does mean .NET wins by default because .NET has always played second banana to Java I doubt anything is going to change on that score. Microsoft seem to know it themselves and are more focused on Xamarin as a niche to crawl into.

          And these days if someone were after a genuinely cross-platform language then there are plenty to choose from, many of which don't carry the baggage of Java or .NET with them.

    • .NET 6 will be a start - truly cross-platform, what Java was supposed to be ....

      I guess I don't understand this dig ... I can write a Swing, AWT GUI hello world proof of concept right now that will run on any Java platform. Or a high performance web server, messaging system, or database engine. .NET Multi-platform App UI won't even support Linux, and the other UI frameworks are very Windows specific? Ok, so something besides GUI frameworks?

      How is Java not truly cross platform, or .NET 6 more so? Sun bent over backwards and did everything to keep Java from getting mired in platform

      • by hjf ( 703092 )

        It's true that Java was as close as "truly multi platform" as it could be.

        But it's also true that "desktop apps" are becoming a niche. Swing, AWT, SWT, are becoming more irrelevant as more and more things move into the browser. Hell, there are "things", like the bank I just switched to, that don't even have a website. Just an app.

        Only old nerds and gamers have computers. Everyone else is more than happy with their "devices", be it a smartphone, tablet, smart toilet, whatever.

        At work, the pandemic has taught

  • by fleeped ( 1945926 ) on Tuesday April 20, 2021 @06:21AM (#61293220)

    The average use-case is definitely not "1,600 projects and ~300k files", so how will this new version perform for the average Joe's projects? Students, researchers, small/medium-sized company programmers, and so on? The worst I've ever seen is 100 projects in a AAA game's solution. Still far from 1600.

    Since they don't say it's going to be better, I'm afraid it's going to be worse...

    • by K. S. Kyosuke ( 729550 ) on Tuesday April 20, 2021 @06:34AM (#61293244)
      I imagine even smaller projects could benefit from memory/speed trade-offs. Running a 32-bit development environment on a machine with dozens of gigabytes of operating memory really may not be the best idea for 2020s. Extra caching and indices always come in handy.
      • While all of this is true, only the compiler, preprocessor etc. has to be 64 bit to gain those improvements. The IDE and all the other trimmings can still be 32 bit with no drawbacks. The only advantage to an all 64 bit VS is that it will be easier to maintain, which is irrelevant to the users who aren't doing that.

        • Apparently I'm of the exact opposite opinion than you are. I was actually thinking of the IDE internals. That is, the compiler, preprocessor etc. don't matter for this. The IDE has its own view of the project's contents. But considering that the IDE handles the whole project at once, for example when searching for things etc., while the compiler does not, I'd argue that it's actually more important for the IDE to be a 64 bit application than it is for the compiler, especially when parallel builds are consid
          • The IDE doesn't do the hard stuff. All it has to do is look up functions. There are not so many of them that you need a 64 bit integer to count them and if you really want your 32 bit process can actually access more than 2GB of RAM so even if they were so large that it became an issue, it would not be an issue.

            The compiler does the heavy lifting, being 64 bit matters there. What the IDE is doing is kiddie stuff by comparison. Maybe some other code-checking tools need to also be 64 bit, but they can be exte

            • The IDE doesn't do the hard stuff. All it has to do is look up functions.

              There's a shitload of functions in a large project, though.

              There are not so many of them that you need a 64 bit integer to count them

              What do 64 bit IDs have to do with this? IDs are not the only thing you might want to remember for a function in an IDE. For example, you might want to remember ASTs of all functions for code analysis or refactoring without having to re-parse things all the time. An AST for a function will take much more than 64 bits. And even that's without all the different indices into your forest of ASTs that you might want to keep. And without versioning, where

              • Why would you use the stupid way of accessing more than 2GB of RAM on a 64-bit machine instead of the smart way?

                I wouldn't. I'd want my code to be 64 bit today. But Microsoft clearly did until recently. They probably had reasons. I imagine they were due to incompetence of some sort, knowing Microsoft. Maybe it was organizational incompetence though, and not programmer incompetence. There's certainly ample evidence of both over there, but I would assume that the VS crew is at least slightly more capable than most other team since people seem to want to use their product on purpose.

          • Weâ(TM)re also working on making every part of your workflow faster and more efficient, from loading solutions to F5 debugging.

            If you want everything to run much, much faster, install VS 2005 or similar. Seriously, that's the single most important thing you can do to improve performance, move back to a version that was bloated but nothing near as bloated as it is now. I do all my dev in 2005 or 2008 and only move to the current version for the final build because I can work about twice as fast in the older versions.

      • by AmiMoJo ( 196126 )

        It's also an opportunity to clean out some legacy crap from the 32 bit era. All the time they were 32 bit only there was pressure to keep supporting old stuff, but now they have an excuse to ditch it. Welcome to corporate politics.

    • how will this new version perform for the average Joe's projects?

      It will consume more RAM. That's the ONLY difference that 64-bit will make.

      • by Pimpy ( 143938 )

        That's sort of the point, even phones ship with more than 4GB now. You sort of want your OS to make effective use of the memory available to it instead of clinging to paradigms that were already outdated in the 90s, kludges like PAE and bounce buffers notwithstanding. 32-bit was crap then and unsurprisingly it hasn't improved with age.

      • by SteelCamel ( 7612342 ) on Tuesday April 20, 2021 @07:43AM (#61293390)

        Not necessarily. 64-bit mode also allows access to extra processor features such as more registers and some extra instructions. I'm not sure if these can be enabled in 32-bit mode, but even if they can the program needs to check for them and provide alternative code for older processors where they're not present. A 64-bit binary can assume that everything that comes with 64-bit mode is present, as it couldn't run otherwise, and simply optimise for the base level of 64-bit features.

        • Not necessarily. 64-bit mode also allows access to extra processor features such as more registers and some extra instructions.

          None of which will make the slightest bit of difference to an IDE.

          • Bullshit. Once they've optimized ReSharper for 64-bit VS it will absolutely make a difference. You can argue why VS and Resharper are such absurd memory pigs, but the facts on the ground prove that they simply are.
      • You also have more registers for the compiler to work with. And some things like hashing might run faster with larger registers as well. Some text algorithms could take advantage of that (Rabin-Karp is a textbook example). Or pretty much any data structures that use bit operations, such as Bloom filters and such. So depending on the internals of VS, there may or may not be some benefits to 64 bits.
      • Comment removed based on user account deletion
        • by AmiMoJo ( 196126 )

          Sometimes I wonder why AMD or Intel have not tried to make 64 bit only CPUs happen. Maybe the trade-off isn't worth it, i.e. the potential savings on cost and on thermal envelope don't justify all the work needed on the software side. Maybe now we are getting some half way competitive ARMs that might change.

      • And disk space. Already made a note to go and buy a 1TB SSD to install this monstrosity on. Anyone else remember when Visual Studio Omniverse Edition was just something to compile your code with? And the depressing thing is they're adding more crap no-one on earth except the geek who dreamed it up cares about while ignoring long-standing bugs (we're talking years here), because adding more bloat is so much cooler than making the existing bloat work properly.

        Like Office, they stopped doing anything usefu

      • Ah, someone that's never tried to work on a big project with extensions installed in Visual Studio.

        Visual Studio crashes ALL THE FUCKING TIME. A lot of my colleagues use Visual Assist X and trade tips on how to keep VS from going OOM and crashing and taking down a whole debugging session with it. Sometimes the answer is "stop using Visual Assist" or something equally stupid, but the only real answer for literally over a decade has been for Microsoft to finally make VS a 64-bit app.

        I care a little less because I use emacs for the actual coding work, so I don't have as many extensions installed, but I've busted the 4GB limit too and it's the fucking worst. Losing a file because you didn't save enough is one thing, losing all your debugging state because Visual Studio crashed makes me want to throw my monitor through a wall.

    • Why would it be worse, lol? Doesn't even make sense. I'm stoked - right now we have large C++ solutions and between VS and ReSharper it's borderline unusable sometimes. I'm really hoping now the ReSharper people can fix that shit.
  • by xack ( 5304745 ) on Tuesday April 20, 2021 @06:36AM (#61293248)
    Mac has been 64-bit only for years now and so are most Linux distros. Meanwhile Windows software outside of games and pro software are still mostly 32-bit. Intel and AMD haven't produced a 32 bit chip for over decade so there should be no reason to not be 64 bit by now. Hopefully with 64-bit Visual Studio most developers will compile in 64 bit mode by default from now on.
    • ...on DEC Alpha boxes. The fact that MS thinks its a Big Deal that their compiler is 64 bit standard in 2021 is just laughable especially given even Intel haven't produced a pure 32 bit chip since the P4 back in 2002!

    • by Misagon ( 1135 )

      A lot of not that much old Windows machines are still running 32-bit Windows though, despite being 64-bit capable.

      That's because machines shipped with 4 GB or less RAM used to get 32-bit Windows pre-installed -- and if it had been 32-bit Windows to start with, every upgrade also got to be 32-bit Windows.

      You can find even 2021-year model laptops with only 4GB RAM, but luckily the habit of pre-installing them with 32-bit Windows is over.

    • Intel and AMD haven't produced a 32 bit chip for over decade so there should be no reason to not be 64 bit by now.

      64bit Windows can't run 16bit Windows applications and is much less backward compatible in general. If you don't need any of the features of a 64bit binary, keeping it 32bit completely makes sense.
      • by DarkOx ( 621550 )

        No it really does not make sense. There are extra registers (big deal) and lots of extra instructions that can be used in a 64-bit binary on x86. Big gains are to be had even in first generation 64-bit hardware over operating in 32-bit mode.

        There is a x32 mode (not widely supported in software) that unlocks some of this while keeping 32-bit memory addressing for savings to be had there from smaller pointers among other things.

        I would argue the increased performance of using 64 bit is a the correct trade to

        • In a lot of cases you still probably be using win64 and just running 3.11 in DosBox or something to host your win16 app or use a VM with XP or older

          Most of this legacy stuff is still being used because it isn't replaceable. From running C&C machines to interfacing with security systems that are no longer sold. A virtual machine wouldn't be the solution at all, as these tend to interface with the hardware they are controlling at a low level. Y2K "issues" and impossibly huge volumes are outside of scope
          • by DarkOx ( 621550 )

            Most of this legacy stuff is still being used because it isn't replaceable. From running C&C machines to interfacing with security systems that are no longer sold. A virtual machine wouldn't be the solution at all, as these tend to interface with the hardware they are controlling at a low level. Y2K "issues" and impossibly huge volumes are outside of scope here

            Well I used to work for a manufacturing firm and we'd virtualized a lot things like the PC's that controlled printing machines and punch presses etc. I am not saying everything can be done this way but quite a lot of it can. Usually the IO on that stuff is serial or parallel and you can pass that through to VM without much trouble. Even if it has custom interface cards if they are at least PCI, or PCARD, they can usually be passed thru to a VM just fine.

            Y2K issues are certainly not out of scope here, a lot

        • Comment removed based on user account deletion
        • If a 32bit build works, and is already satisfactory in terms of performance, and doesn't need the extra RAM 64bit gives you access to, going to 64bit isn't going to achieve a whole lot. And 32bit is good enough for a lot of apps.

      • by AmiMoJo ( 196126 )

        32 bit Windows can't use more than 4GB of RAM normally, and 32 bit apps running on 64 bit Windows can't use more than 4GB of RAM.

        I think the main reason a lot of apps are still 32 bit is that people figure that they might as well support the many 32 bit machines still out there. Microsoft only stopped releasing 32 bit Windows to OEMs last year.

        • by tlhIngan ( 30335 )

          I think the main reason a lot of apps are still 32 bit is that people figure that they might as well support the many 32 bit machines still out there.

          Or more importantly, the app has plugins. 32-bit plugins can't be run in a 54-bit process without a 32-bit helper program.

          Some applications, like Microsoft Office, have a long history of plugins and many companies have custom-developed plugins that run under Office. This is why Office asks which version you want to install - 32bit for compatibility with old p

    • Backward compatibility is kind of a religion to MS. On the other hand, Apple are happy to break stuff, to deem hardware over 3 or so years old to be 'vintage' and drop support, and so on. Apple don't care if old software doesn't run on new OS X. MS does.

      • Exactly and precisely this. Microsoft gives a shit if your old-ass Word or Excel add-ins break because they are 32-bit but suddenly Office is 64-bit. So they're slower to move and most of the time it doesn't matter but VS should have moved over 2 versions ago.
      • Probably because Apple makes their money selling hardware and not operating systems, so making older machines obsolete ASAP directly helps their bottom line.

    • Mac has been 64-bit only for years now and so are most Linux distros. Meanwhile Windows software outside of games and pro software are still mostly 32-bit. Intel and AMD haven't produced a 32 bit chip for over decade so there should be no reason to not be 64 bit by now.

      The issue for many programs there is no affirmative reason at all to release 64-bit software for Windows platform. Most programs will not run any better or differently and are not any more compatible. There is no tangible benefit.

      In fact there are some nice properties of 32-bit apps. They use less memory and should they go haywire from memory leaks can't run the OS out of memory. You can't limit process memory with desktop versions of Windows.

      Hopefully with 64-bit Visual Studio most developers will compile in 64 bit mode by default from now on.

      In VS 64-bit has been a compiler setting forever. On other p

  • The article says it will be lighter, no longer bound by the 4GB memory limit.
    How does that work?

    • by Niggle ( 68950 )

      The article says it will be lighter, no longer bound by the 4GB memory limit.
      How does that work?

      Visual Studio runs as a dozen or more processes currently. The main reason for that is that if it ran as a single process it would easily pass the 4GB limit. So going to 64bit could allow processes to be combined and a lot of inter-process communication could be dropped. Which could make it lighter overall, though the combined processes would look a lot fatter.

      • going to 64bit could allow processes to be combined and a lot of inter-process communication could be dropped. Which could make it lighter overall, though the combined processes would look a lot fatter.

        Also: A single bug will now crash the entire IDE where it used to only crash a single editor tab (or whatever).

        This is the reason your web browsers now spawn a process-per-tab - to keep pages separate from each other

  • by Viol8 ( 599362 ) on Tuesday April 20, 2021 @06:52AM (#61293286) Homepage

    You know, minor stuff such as library and include paths that are currently buried 3 or 4 levels down in obscure menus and updated via a dialog box seemingly designed in 1985 while irrelevant crap such as Team Explorer gets top billing in View menu?

    • by Anonymous Coward

      Don't worry!

      * An update UI meant to reduce complexity

      Translation: The entire UI will be completely fucked and you won't be able to find anything. Guaranteed.

      You want to make the UI better? Then leave it alone and quit fucking changing things.

      • Wish I had mod points. In fact pretty much everything in that list can be replied to with "it wouldn't need fixing if you didn't keep fucking with it (a.k.a. fucking it up)".
    • Personally I find Azure Devops (previously Team Foundation Server) is great either as a personal code repository or for small teams. I don't imagine it would scale well for large teams as it stands right now, but the market for small to medium size shops is enormous and shouldn't be ignored.
    • The 'command palette' from VSCode needs to be in Visual Studio pronto. That thing is a huge time saver.

  • https://spacemacs.org/ [spacemacs.org] is your desktop or headless-over-SSH powerhouse.
  • An update UI meant to reduce complexity and which will add integration with Accessibility Insights. Microsoft plans to update the icons and add support for Cascadia Code, a new fixed-width font for better readability

    if this involves the ribbon, I'll start developing in libreoffice as well...

  • No more flat icons? (Score:5, Interesting)

    by UnknownSoldier ( 67820 ) on Tuesday April 20, 2021 @08:07AM (#61293442)

    WOW. Someone at MS finally got a clue stick that "flat" icons suck. This is a good step in the right direction.

    old vs new icons [microsoft.com]

    • Still using the CGA color palette as well.

    • They also seem to have a bit more of color in them which is a good thing because it makes them easier to find at a glance.
      It's a middle ground between "classic" colorful icons and monochrome ones (hard to tell apart, only the shape did distinguish them). A step in the right direction IMO
    • No, it's still the same wank, just slightly different wank. You can tell from the announcement, any time you see the term "refresh" used in relation to a UI then what it means is "the bunch of latte-sipping hipsters we pay a ton of money to hang around the offices have run out of things to do, so they've thrown out the old UI and replaced it with a new one that's more or less the same in appearance but completely different in functioning so you'll have to start again from scratch". "UI" and "refresh" are
    • by AmiMoJo ( 196126 )

      I wouldn't say either set is universally better.

      For example the two sheets of paper (copy?) one looks better in the original flat form, where as the floppy disk looks better in the new set.

      The new ones are mostly an improvement, the use of colour making it easier to see what they are. Microsoft screwed up the flat design by not using enough colour or separation - the copy icon works because the two sheets are well separated from each other. The new copy icon sucks because for some reason the paper is now tr

  • by Murdoch5 ( 1563847 ) on Tuesday April 20, 2021 @08:18AM (#61293474) Homepage
    The biggest single awaited feature is still missing, Linux support! If you're going to use an IDE as a professional developer then you need it to work across a reasonable amount of platforms, and to lack Linux support is simply indefensible.

    Will it finally have a fix for the garbage handling of JavaScript, TypeScript, HTML, CSS?
    Will the auto formatter stop making a total mess of CSS files?
    Will it stop taking 5+ minutes to load (on a good day), seemingly for no reason?
    Will it stop locking up the entire system before forcing a reboot?

    Maybe VS 2022 will finally be "The Good Release", but I doubt it, however may as well wait until the real reviews come in, and we can see what we're really dealing with.
    • by Guspaz ( 556486 )

      I'd take "actually works well on Windows" before getting a Linux or macOS port. VS2019 runs like a dog even on a 5950X. Every single interaction with the IDE is just laggy, lots of micro-delays everywhere.

      • On a 5950X? That's inexcusable!

        On my old notebook it use to take 10+ minutes to start and load the project, and sometimes it would lock up while doing that and crash, that was when I stopped using it and moved to WebStorm.
        • by gTsiros ( 205624 )

          i don't get it

          what do you have loaded on your vs?

          on my 5950x with 64GB @3600MHz and a 500GB samsung 960evo

          it loads the entire solution of the .net source code in 7.5 +-0.5 seconds

          btw do you have any cache hierarchy errors on your 5950x?

    • The biggest single awaited feature is still missing, Linux support!

      Sorry, I'm having trouble parsing that. The fact that it can't infect Linux is a feature, but you're saying it's not?

    • by Tanaka ( 37812 )

      Rider is hands down the best IDE right now for C#. And it runs great on Linux. The only thing it's missing, is automated remote debugging support. If you do anything with IoT/Raspberry Pi's, then please up-vote this https://youtrack.jetbrains.com/issue/RIDER-59477

    • Visual Studio doesn't, but Visual Studio Code does.

    • Maybe I just don't do enough of the fancy stuff to notice, but I use https://geany.org/ [geany.org] as my primary programming editor and like it rather a lot.

      But again, maybe I just don't do enough fancy stuff with it. I pretty much just use it for editing C so I don't know how well it actually performs with some of that modern whippersnapper stuff like Java. :)

  • The Visual Studio IDE has been 32bit since day one. This has been a huge PIA for a small number of people. A 64bit IDE is the BFD, not the compiler, and I'm ecstatic that they are finally fixing this.

    If you published a .NET DLL that provides a Form, built with native code via CLI, then you absolutely HAD TO ship a 32bit version so that the 32bit IDE could load your DLL into the Forms Designer so others could use it. Even if none of your customers every wanted to build a 32bit version.

    Now we can finall

  • by nickovs ( 115935 ) on Tuesday April 20, 2021 @09:17AM (#61293644)
    If moving to 64 bit is a big deal then you're clearly doing something wrong. Not from the users' point of view; clearly this will bring some user benefits. But if rebuilding your application to work on a 64-bit runtime with 64-bit libraries takes anything more than recompiling the existing code with new compiler flags then what does that say about the code?

    If this is a big deal for Microsoft then that implies that the code is riddled with assumptions and probably has terrible type casting discipline. It suggests that there are places where it has some constant that represents the size of some structure and if someone else were to change that structure it would break, because the constant is hard-wired rather than calculated by the compiler. It says that the code has insufficient and/or incorrect abstractions about the platform underneath it. It basically says that it's full of all the sorts of code smells that lead to bugs, instabilities and vulnerabilities.

    Visual Studio has available for 24 years. The fact that it was a heavy lift to move to 64-bit probably has its roots in a code base that's quarter of a century old. At one level I'm just glad I'm not its product manger, but at another level I can't help thinking: if the people writing the IDE write code like this, do I really want to trust the development of my critical projects to their tools?

    • You are being a bit unfair here. Only in toy projects you switch a flag and everything works. Complex projects have to do architecture-specific optimisations, and the nature of being a real-world project (and a complex one, that is) implies that code quality is secondary to actually meeting deadlines and producing things that might entice people/organisations to buy your product, so that you can continue working on it. Features sell easier than bugfixes... (even if said features are bloat)

  • "Integration of text chat into the Live Share collaboration feature" yes, cause there are so few chat options...
    • What a nightmare...

      I bet it's Teams integration which means half the time it won't work without restarting VS (if at all). Most of the the rest of the time it just won't work as expected and lead to application freezes and other "collaborative disruptions" (the collaboration being between you and the computer...).

      The last thing I want my IDE to have is chat. Just another avenue to interrupt my concentration.

8 Catfish = 1 Octo-puss

Working...