Visual Studio 2022(devblogs.microsoft.com)
devblogs.microsoft.com
Visual Studio 2022
https://devblogs.microsoft.com/visualstudio/?p=232313
107 comments
Only a decade too late on the move to 64-bit
Rico Mariani, the "perf guy" at Microsoft, had this opinion on VS 64-bit in 2009:
https://web.archive.org/web/20160309232651/http://blogs.msdn...
https://web.archive.org/web/20160309232651/http://blogs.msdn...
This was a stupid take even then.
Performance in Visual Studio has become such a problem that I've renounced it entirely in favor of Rider.
Performance in Visual Studio has become such a problem that I've renounced it entirely in favor of Rider.
This is where I am, too - long time .NET dev, have gotten increasingly frustrated with Visual Studio's awful performance, especially with ReSharper. I've tried taking that out given VS has a bunch of that stuff built in, but working without R# completions feels like trying to work with one arm tied behind my back.
Between that and my preference for Macs for my personal laptops -- and I've been very excited at how good .NET Core has gotten on non-Windows platforms -- as well as a ~3 year sojourn working with Java 8/11 in IntelliJ, I've gotten very comfortable working with JetBrains IDEs and generally prefer them when I have the option. Structure View is great, the search is nice and snappy.
The only thing that frustrates me with Rider is I don't think you can apply fixes from Roslyn analyzers at the file/project/solution level like you can in VS. We enforce our team's coding standards using those, so it's a minor pain point, but not enough to get me to stop using Rider given how much faster it is.
Between that and my preference for Macs for my personal laptops -- and I've been very excited at how good .NET Core has gotten on non-Windows platforms -- as well as a ~3 year sojourn working with Java 8/11 in IntelliJ, I've gotten very comfortable working with JetBrains IDEs and generally prefer them when I have the option. Structure View is great, the search is nice and snappy.
The only thing that frustrates me with Rider is I don't think you can apply fixes from Roslyn analyzers at the file/project/solution level like you can in VS. We enforce our team's coding standards using those, so it's a minor pain point, but not enough to get me to stop using Rider given how much faster it is.
Having worked mostly on solutions with at least one Web project in the mix, it's even worse. I absolutely love VS Code, but VS itself is a beast that I just avoid opening if I can at all avoid it.
VS Code isn't quite as good on C# projects, I will admit, but still so much better (less blocking) in general.
Not familiar with Rider though.
VS Code isn't quite as good on C# projects, I will admit, but still so much better (less blocking) in general.
Not familiar with Rider though.
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.
What a horrible thing to say to your customers.
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?
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.
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.
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.
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.
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.
It’s easy to rationalize yourself into this kind of opinion when you know there would be a monumental amount of work to get to 64 bit. I know this blogger is respected and the post influential, but that doesn’t make him right. Notably absent in his post is any kind of benchmark or data to support his opinion.
Meanwhile, are there any examples of modern applications being written in 32 bit for performance reasons? Not that I can think of, or at least nothing that is meant to run on a 64 bit PC.
There’s a lot you can do with extra memory headroom, especially when developers usually have 16 or 32 GB to work with.
Meanwhile, are there any examples of modern applications being written in 32 bit for performance reasons? Not that I can think of, or at least nothing that is meant to run on a 64 bit PC.
There’s a lot you can do with extra memory headroom, especially when developers usually have 16 or 32 GB to work with.
Generally performance gets better mostly because x64 arch has more registers.
That being said, I really wish the X32 ABI in linux had garnered more interest. The concept is that it's 64-bit code that runs with a 32-bit memory space. All your pointers can still be 32 bits but you also get all the architectural advantages of 64-bit mode too. In theory you should get the perf benefits of 64-bit without the perf costs.
The ABI wasn't really used much, so it got removed. But it was a bit self fullfilling. We never wanted to switch to it because it had poor surport from distributions, but distributions didn't bother supporting it because nobody used it!
That being said, I really wish the X32 ABI in linux had garnered more interest. The concept is that it's 64-bit code that runs with a 32-bit memory space. All your pointers can still be 32 bits but you also get all the architectural advantages of 64-bit mode too. In theory you should get the perf benefits of 64-bit without the perf costs.
The ABI wasn't really used much, so it got removed. But it was a bit self fullfilling. We never wanted to switch to it because it had poor surport from distributions, but distributions didn't bother supporting it because nobody used it!
To the downvoters, what is your issue with this statement?
Huh, why does this still exist if there's VS Code?
There is no comparison between the two. VS is the _real IDE_ while VSCode is a text editor like Sublime Text
While I agree, VS does a LOT more than VS Code does... VS Code is also a lot more than Sublime Text.
I would also say that VS Code's plugins don't block the world. Web projects in VS are absolutely painful in general.
I would also say that VS Code's plugins don't block the world. Web projects in VS are absolutely painful in general.
Same reason other IDEs exist. VS Code is just the tip of the iceberg.
More powerful debugging, more mature UI development tools, does a bit more for you.
I love VS Code but it's no replacement for Visual Studio when developing .NET apps.
Other than legacy technology like WYSIWYG form builders, Visual Studio Code has the same functionality but with a simpler, superior interface. Visual Studio is a legacy product, it’s that simple, although a lot of people don’t seem to want to accept it.
For me VS has more reliable IntelliSense.
Literally the only reason I'll jump into it for C# projects now and then... Spend most of my time in VS Code for what I work on more, but will still open VS now and then when a C# solution is just a bit too much. It's gotten a lot better though.
No it’s not. VS Code doesn’t allow you to view/manage threads, modules for example which are crucial for a bit more advanced debugging. I love VS Code and use it daily, but it’s no replacement for VS yet.
Designers is just one of a handful of things. The perf analysis tools for example don’t exist in vscode. You can compensate by using a separate profiler but that just drives home the point that VScode replaces only some parts of VS.
Visual Code has a simpler interface because it has a fraction of the functionality.
https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv...
"80% of the people use 20% of the features... Unfortunately, it’s never the same 20%."
> legacy technology like WYSIWYG form builders
Kind of a weird statement to make -- who doesn't use WYSIWYG when working in XAML? Nothing legacy about that.
https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv...
"80% of the people use 20% of the features... Unfortunately, it’s never the same 20%."
> legacy technology like WYSIWYG form builders
Kind of a weird statement to make -- who doesn't use WYSIWYG when working in XAML? Nothing legacy about that.
It does a ton more than VS Code, especially for large Windows applications and C++ stuff.
[deleted]
Why does the hammer still exist if there's pliers?
Visual Studio supports some legacy technologies that VSCode likely won't ever support well.
Even ASP.NET Core which was specifically designed to allow development exclusively from the terminal, still offers a better experience in the full VS Than VSCode (even if JavaScript/CSS/TS/etc part is arguably better in VSCode, the C#/.Net side is better in VS).
But long term: I anticipate VS being a life-support product for that legacy tech and VSCode being the only IDE they move forward with. We just aren't quite there yet.
Even ASP.NET Core which was specifically designed to allow development exclusively from the terminal, still offers a better experience in the full VS Than VSCode (even if JavaScript/CSS/TS/etc part is arguably better in VSCode, the C#/.Net side is better in VS).
But long term: I anticipate VS being a life-support product for that legacy tech and VSCode being the only IDE they move forward with. We just aren't quite there yet.
A compiler vs a basic IDE, yeah, totally the same.
Because it's more stable, has better debugger, testing, etc. In Visual Studio Code I feel like things might break if just update it, or the plugin/extension got updated. Also you can keep the whole team in the same "boat" with single IDE, and your IT would know how to respond.
I tried out VSCode after all the rage and was pretty underwhelmed.
It looked like a lightweight syntax highlighter plus a JS extension marketplace.
I remember VS was a real well integrated IDE back when I used it. Something in the same league as IntelliJ, etc. VSCode wasn't in the same league at least for me.
I remember VS was a real well integrated IDE back when I used it. Something in the same league as IntelliJ, etc. VSCode wasn't in the same league at least for me.
Same here. I'm one of those people that try VSCode every few weeks because "it's free and it would be nice to have a more lightweight IDE for some stuff". But coming from IntelliJ it is really hard. It feels like a lot of convenience and stuff "that just works" is somehow there, but not working on the same level the "old" full fledged IDEs. You can notice the optimizations that gone into the auto complete features and similar. Tried Python, Go, Java and Kotlin in VSCode. Just couldn't compare. Granted. At least Java and Kotlin might not be languages that work well in non specialized IDEs.
I really loved the remote execution feature of VSCode. But in the end it resulted in me programming in IntelliJ and then copy and pasting the code over to VSCode...
For me it feels like the modern Eclipse. The one IDE/Editor which is basically a container for thousands of plugins. And it's great. Everyone uses it. There are a lot of plugins that cover every imaginable use case. Even more than e.g. IntelliJ or Visual Studio could cover (ok maybe not). But in the end it's just not as great as an IDE with most core features already build in and tuned against each other.
But then there are also people using unmodified vim installations for programming. So the expectations and ways of working really seem to differ a lot.
I really loved the remote execution feature of VSCode. But in the end it resulted in me programming in IntelliJ and then copy and pasting the code over to VSCode...
For me it feels like the modern Eclipse. The one IDE/Editor which is basically a container for thousands of plugins. And it's great. Everyone uses it. There are a lot of plugins that cover every imaginable use case. Even more than e.g. IntelliJ or Visual Studio could cover (ok maybe not). But in the end it's just not as great as an IDE with most core features already build in and tuned against each other.
But then there are also people using unmodified vim installations for programming. So the expectations and ways of working really seem to differ a lot.
VS Code is a glorified text editor (which isn't bad, I use it). Visual Studio is a full-fledged IDE.
VS Code has things like refactoring support and integrated debugging which are traditionally seen as the dividing line between an IDE and a text editor. How are you defining that distinction?
If I write a C++ program in VS Code how do I build, debug, or profile it?
https://marketplace.visualstudio.com/items?itemName=ms-vscod... claims to support it. I haven't used it in C++ but if it follows the pattern of Rust, Python, JavaScript, TypeScript, or Java once you have the appropriate language extension installed the built-in debugger will work transparently.
Nope.
Nope as in you haven’t tried it, the instructions at https://code.visualstudio.com/docs/cpp/cpp-debug are wrong, etc.?
I have tried it.
The page says you need to install a compiler. The debugging page says GDB. It doesn't ship with these does it? That's all I'm saying.
The page says you need to install a compiler. The debugging page says GDB. It doesn't ship with these does it? That's all I'm saying.
Ah, so from my perspective that's not a question of whether it's an IDE or not but whether it bundles third-party code or lets you install it using the standard package manager for your platform. In the Unix world the latter is typically considered a feature, especially for a polyglot editor which supports a number of languages and tools which are all developed by different groups on schedules which are not coordinated.
I'm with you on this one... While the VS Installer has checkbox options for X or Y... a lot is in the box regardless of what you're actually using/targeting.
A lot of the tooling options with VS are getting better month over month even. There's a reason why a fair number of developers for Go, Rust, TypeScript and other languages are absolutely preferring VS Code over other options...
A lot of the tooling options with VS are getting better month over month even. There's a reason why a fair number of developers for Go, Rust, TypeScript and other languages are absolutely preferring VS Code over other options...
If you use the Remote Containers feature, then it effectively does ship with those. You run the command to set up a C++ dev environment for your project, and it downloads a Docker image from Microsoft's registry that has those tools installed in it, and lets you work and run your code inside that image.
(You do still have to separately install Docker. I guess this is because Docker puts a lot of global state on the machine, so having VSCode try to manage a separate copy of it would cause too many problems.)
(You do still have to separately install Docker. I guess this is because Docker puts a lot of global state on the machine, so having VSCode try to manage a separate copy of it would cause too many problems.)
Need to play with the Remote Containers feature a bit more... I use WSL remote the vast majority of the time myself, and the SSH remote has been invaluable for a couple of more finicky server setups for my own one-off projects.
The terminal used with VS Code (and Hyper) needs a bit of work though... it gets wonky now and then, good enough most of the time, until it isn't.
The terminal used with VS Code (and Hyper) needs a bit of work though... it gets wonky now and then, good enough most of the time, until it isn't.
Yep.
I use it often. It doesn't do profiling but building and debugging works fine (though I still prefer VS proper).
I use VS on Windows, VS Code on Mac for the same code base. I have for decades in the former and years in the latter (finally ditching XCode might have been one of the best decisions I've ever made with regard to my tooling).
I use it often. It doesn't do profiling but building and debugging works fine (though I still prefer VS proper).
I use VS on Windows, VS Code on Mac for the same code base. I have for decades in the former and years in the latter (finally ditching XCode might have been one of the best decisions I've ever made with regard to my tooling).
[deleted]
I only used VS in recent years for unity development
You can't compare - VS is way ahead of VSC in terms of code completion and IDE<->engine integration
You can't compare - VS is way ahead of VSC in terms of code completion and IDE<->engine integration
Maybe someday we will have only a base simple VS Code and be able to extend it to do anything we want with plugins, and transform it into a full Visual Studio if we want. But not yet. As of now I only use VS Code for Typescript dev with React and Node and stuff. And good old VS for .NET dev.
When it uses even 3GB (open a 100 project sln) it’s excruciatingly slow as it is. It’s also already not limited to 4GB because it consists of multiple processes. I can’t see how being able to use 10GB or 20GB in the main process will help.
64 bit is an improvement IMO. If the main process has more memory to work with, then it’s easier to keep things in memory and in a single process where you don’t have to incur IPC overheads.
As mentioned elsewhere, the switch does increase pointer sizes, but I’d be very surprised if that is significant compared to the amount of memory used by strings and other data.
As mentioned elsewhere, the switch does increase pointer sizes, but I’d be very surprised if that is significant compared to the amount of memory used by strings and other data.
My point is: this no one can live with being near the memory limit in VS as it is. If you have an OOM you already waited for hours each day with the program “not responding”. I’m not saying it’s a net negative e.g due to pointer sizes (it’s very rarely the case in my experience perhaps since the x64 JIT is better than x86 so x64 is usually better or equal despite more memory use) but it also not an obvious positive and the effort must be nontrivial and should perhaps have been spent at fixing some fundamental perf issues.
Like the sln mess that makes switching build configs a 15 minute wait on a large solution.
They might have fixed perf issues also but I’m not optimistic.
The chance for this being a general perf win is if there was overhead involved in the separation into devenv and supporting processes that can now be cut by making it all one process again.
Here’s to hoping they have also done some big changes under the hood, perhaps enabled by the switch to x64.
Like the sln mess that makes switching build configs a 15 minute wait on a large solution.
They might have fixed perf issues also but I’m not optimistic.
The chance for this being a general perf win is if there was overhead involved in the separation into devenv and supporting processes that can now be cut by making it all one process again.
Here’s to hoping they have also done some big changes under the hood, perhaps enabled by the switch to x64.
Mac is only getting an updated UI? That’s a huge shame. It’s been out for years and there’s still no C++ support. VS Code is decent if you use Cmake, but the code completion and highlighting is really off compared to native VS.
Is there any decent alternative to a good C++ IDE for Mac besides Clion (which costs money).
Is there any decent alternative to a good C++ IDE for Mac besides Clion (which costs money).
Honestly just pony up for CLion. It is actively developed (support for makefiles and arbitrary build systems was just added in addition to the existing CMake) and JetBrains has a super reasonable subscription that lets you keep the last version you had indefinitely if you ever cancel.
I’ve tried to like the JetBrains stuff (especially Clion) but I just have never gotten to the point where I love it.
I've found that to really get the most value out of Jet rains IDEa you have to go out of your way to discover the built-in features and use them, things like the built-in debugger, git support, find in project, search by symbol, etc. There's a LOT in there and easy to ignore or gloss over.
A way to learn is to take the time to read the tip of the day and try out the suggestion right away. Don't disable the tip of the day. It only takes one minute a day and after about a month you'll have learned a lot.
Yeah, CLion is just superior to any other C++ IDE out there.
That's probably because VS for mac is not really "VS" but a re-skinned Xamarin IDE
If you can get used to some oddities, Xcode works well enough for any C++ code you write yourself, or have enough control over to make sure you follow the conventions it expects.
But if you need CMake support within your IDE, CLion's worth it, just get the JetBrains subscription (student or professional) and don't look back. Oddly enough when I last used it, CLion didn't work with Clang-based projects quite as nicely as Xcode (it preferred GCC) but that might have changed since then.
Finally, if you want to support open source, you can try VS Code. It mostly works, but it's not an IDE.
Eclipse CDT also exists, but ... I think the last time I tried eclipse was back in the mid-2000s before RubyMine when there was a Ruby-on-Rails plugin for Eclipse. I haven't looked back since...
But if you need CMake support within your IDE, CLion's worth it, just get the JetBrains subscription (student or professional) and don't look back. Oddly enough when I last used it, CLion didn't work with Clang-based projects quite as nicely as Xcode (it preferred GCC) but that might have changed since then.
Finally, if you want to support open source, you can try VS Code. It mostly works, but it's not an IDE.
Eclipse CDT also exists, but ... I think the last time I tried eclipse was back in the mid-2000s before RubyMine when there was a Ruby-on-Rails plugin for Eclipse. I haven't looked back since...
Clang and LLDB work fine now
Hoping they can fix the "Intellisense operation in progress" pane from ever appearing again.
I don't know what they did in VS2019 but there was clearly a ridiculous perf hit in many modules, especially Intellisense related.
While I sort of liked the AI-predictions, they introduced a serious lag in typing and every couple of seconds typing would nearly freeze. After I turned those off, typing became smoother but still slightly laggy (sort of like typing on a remote terminal on the other side of the world), and the predictions would pop up much slower than VS2017.
Lots of other perf issues like "Find in files" being 3x slower than in VS2017. Or adding a new class to a file wastes several seconds looking up templates somewhere. I saw dozens of bugs filed for these issues over the past few months and most were resolved as "Fixed" (allegedly) or "No repro" but in practice the IDE perf is still IMO unacceptable.
I really hope they fixed that stuff with VS2022.
While I sort of liked the AI-predictions, they introduced a serious lag in typing and every couple of seconds typing would nearly freeze. After I turned those off, typing became smoother but still slightly laggy (sort of like typing on a remote terminal on the other side of the world), and the predictions would pop up much slower than VS2017.
Lots of other perf issues like "Find in files" being 3x slower than in VS2017. Or adding a new class to a file wastes several seconds looking up templates somewhere. I saw dozens of bugs filed for these issues over the past few months and most were resolved as "Fixed" (allegedly) or "No repro" but in practice the IDE perf is still IMO unacceptable.
I really hope they fixed that stuff with VS2022.
Or my favorite....closed due to lack of community response.
Yeah.. I mean, I understand metrics... but there are some things that just won't see broad complaints, but are indeed issues. Not everyone will be a squeaky wheel, doesn't mean those "less interaction" issues aren't meaningful/bad. Not to mention having to create yet another profile to even interact with the issues... if an issue is created, I won't always login even to give a +1/heart on something.
I had the same experience moving from visual studio 2017 to visual studio 2019. I tried disabling every possible IntelliSense related feature and there was always a small but perceptible amount of input latency that drove me crazy.
Eventually I was forced to switch over to jet brains rider and I haven't looked back since, which is a shame because I really enjoyed using the previous versions (2010, 2012, 2015, and 2017).
Eventually I was forced to switch over to jet brains rider and I haven't looked back since, which is a shame because I really enjoyed using the previous versions (2010, 2012, 2015, and 2017).
Before clicking the link I was going to joke, "But is it 64-bit yet?" So I was pleasantly surprised :D
Didn't they make a huge deal about explaining why 64 bit was a bad idea?
> With a 64-bit Visual Studio on Windows, you can open, edit, run, and debug even the biggest and most complex solutions without running out of memory.
> I find it really satisfying to watch this video of Visual Studio scaling up to use the additional memory that’s available to a 64-bit process as it opens a solution with 1,600 projects and ~300k files.
I guess the popularity of Node.js finally broke them.
> With a 64-bit Visual Studio on Windows, you can open, edit, run, and debug even the biggest and most complex solutions without running out of memory.
> I find it really satisfying to watch this video of Visual Studio scaling up to use the additional memory that’s available to a 64-bit process as it opens a solution with 1,600 projects and ~300k files.
I guess the popularity of Node.js finally broke them.
>> Didn't they make a huge deal about explaining why 64 bit was a bad idea?
Yes, they did.
I remember very well multiple MS employees who were present at a conference I attended, explaining the counter-intuitive 'notion' that VS would be worse off in 64-bit.
At the time it seemed it ridiculous to me.
Yes, they did.
I remember very well multiple MS employees who were present at a conference I attended, explaining the counter-intuitive 'notion' that VS would be worse off in 64-bit.
At the time it seemed it ridiculous to me.
Seems to me the declared bad idea was for time/budget concerns, and only minorly because of technical concerns.
The architect who was responsible for that has a recent blog post on it: https://ricomariani.medium.com/visual-studio-why-is-there-no...
N.B. recently reposted, but originally written in 2009.
I'm not sure if the 64-bit thing solves anything. I mean I use rider with a 1,5gig heap and it is basically fast. visual studio was always slow and 64-bit probably won't change that.
This ^^^ - Longest waiting for this to happen. Solves quite a lot of issues - from not having to support 32-bit for your own extensions, designer forms, etc. to have tests run in the IDE, to not have plugins/extensions all go IPC which is probably not without problems.
Amen. Latest related issue I've run into: Visual Studio ships its own 32-bit Git binary, and getting that to play nicely with the native Windows OpenSSH for Git authentication is... not fun. https://developercommunity.visualstudio.com/content/problem/...
I hope this is one step closer to ARM64 support!
At a previous job we were repeatedly running into memory pressure issues and had talked about converting to a 64-bit application on and off for years. It was something I had pushed for as we were doing increasingly baroque work-arounds and I was asked to do some work to estimate what it would take to convert over. Ultimately it was decided not to do so and one of the repeated reasons that was cited for why we shouldn't was "Visual Studio isn't 64-bit, why are we so worried!?" Suffice it to say, I found that reasoning pretty frustrating and I am curious to know what will happen now that VS can no longer be cited.
Most of your 32 bit extensions probably won't work on the 64 bit version. I'd wait a year or so before bug testing for Microsoft.
> Updated icons for better clarity, legibility, and contrast.
I feel like a lot of these are at best _different_. The entire bottom row of icons in their comparison seem FAR FAR less legible, especially the X, Check and i icons
I feel like a lot of these are at best _different_. The entire bottom row of icons in their comparison seem FAR FAR less legible, especially the X, Check and i icons
I see what you mean about the check, info, and cross icons (which should be. But overall I have to say it is an improvement. The new icons are much more clearly designed around a dominant color and shape, which, incidentally, is what makes recognizing them a lot easier.
You're telling me you knew that was a broom and not a showerhead?
Even on the old one, I wouldn't be sure what it was tbh. Thank god for tooltips and mouseover actions in general. It's the one thing a touch based UX misses more than anything, and probably why, even though I can do more on my phone, there's still a lot of things I'll head over to a computer with a keyboard/mouse to do anyway.
I have keratoconus and limitations on how well
my vision can be corrected. The new icons all look blurry to me while the old ones are clear.
I long for the crisp pixel-based icons of old. They take more work and experience to design, and nowadays you'd have to create them in multiple sizes to cover different DPI, but they were so much better than today's vector-based icon graphics.
And I wonder why they turned the floppy icon upside down. Maybe to make it consistent with their floppy emoji? ;)
And I wonder why they turned the floppy icon upside down. Maybe to make it consistent with their floppy emoji? ;)
I think it is largely a design issue. HaikuOS has vector icons everywhere that are as crisp as their pixel-based counterparts (in fact many of them are recreations).
HaikuOS' icon format was designed specifically for vector icons and has support for "LODs" to hide/show elements based on the zoom level but i think (though not 100% sure) that other vector formats can do that too.
HaikuOS' icon format was designed specifically for vector icons and has support for "LODs" to hide/show elements based on the zoom level but i think (though not 100% sure) that other vector formats can do that too.
Visual Studio's UI is written in WPF and there's native support for pixel-pitting vector graphics, exactly for the purpose of icons and other things that, while vector, must be aligned to device pixels. I think I remember seeing that at least the old icons definitely made use of that (you can download the whole icon packs for VS2012–2019 somewhere on the Microsoft site). And I think you should also be able to do LOD; it's possible with SVG with media queries; you should be able to do this with XAML at the very least via injecting size information via a data context.
I would have no idea what the new dark mode camera icon was if it wasn't next to the old camera icon. Light mode seems better but not by much.
Ok, with this new x64 version, should we rewrite the extensions? Does extensibility API changes?
Not sure but this upcoming (Friday April 23) talk by Mads Kristensen should have the answer: https://www.youtube.com/watch?v=L8b3kFriwCs
I'm surprised they're not porting the windows full fledged version over to Mac. I've used the VS for Mac edition and it's lacking too many useful features that come with vscode out of the box (ex. emmet)
That's because the Mac version (at least initially) was a replastered version of the Xamarin client.
I kind of miss the simplicity of SharpDevelop at times... Haven't touched it in years and the Xamarin Studio (Now VS for Mac) never felt as nice to me.
These days, I spend most of my time in VS Code, I frankly don't know if it's less overhead than VS, but it's definitely more responsive. I can't stand working on web projects in VS proper. The plugin model for Code just seems to work so much better in practice. Definitely learned from the past, even if it's a web app, it still works really well compared to alternatives. Integrated terminal and unobtrusive directory tree are godsends.
These days, I spend most of my time in VS Code, I frankly don't know if it's less overhead than VS, but it's definitely more responsive. I can't stand working on web projects in VS proper. The plugin model for Code just seems to work so much better in practice. Definitely learned from the past, even if it's a web app, it still works really well compared to alternatives. Integrated terminal and unobtrusive directory tree are godsends.
Seeing the new colored icons reminds of me of the debacle when Visual Studio 2012 was released. They decided to replace almost all of the icons with a monochrome version, effectively removing the color-cues that developers were used to using for quickly finding an icon.
They eventually relented on this and started moving color back into the development environment. Now they're just tweaking the icon appearance and leaving the colors intact.
They eventually relented on this and started moving color back into the development environment. Now they're just tweaking the icon appearance and leaving the colors intact.
Was VS 2012 the first release with the menu bar THAT SCREAMED AT YOU for no good reason?
The first thing I did was track down a registry tweak to make the menu bar not be in all capital letters.
The first thing I did was track down a registry tweak to make the menu bar not be in all capital letters.
Sure was, I forgot about that one.
https://devblogs.microsoft.com/visualstudio/a-design-with-al...
https://devblogs.microsoft.com/visualstudio/a-design-with-al...
I remember that. They justified it by pointing to a similar all caps navigation bar on MSDN, as if that trumped some 25+ years of precedence for workstation apps. ¯\_(ツ)_/¯
Every time I try to use Visual Studio as just a text editor I find its behaviour of spaces/tabs a complete disaster. I know that heaps of people use it and love it, so I can tell that it must be me that is the weirdo, but is it too much to ask for:
1) Pressing tab inserts a tab 2) Pressing space inserts a space 3) Pressing enter inserts a newline, with the new line starting with the same whitespace as the previous line 4) Pressing shift-tab removes the leading tab from the start of the current line, or N(=4) spaces from the start of the current line
No surprises, no auto-formatting, no having to go and reconfigure your text editor behaviour when you find random files with different conventions, no modelines etc. I see the huge depth of preferences in VS, and think it must be possible, but every time I come away less confident.
1) Pressing tab inserts a tab 2) Pressing space inserts a space 3) Pressing enter inserts a newline, with the new line starting with the same whitespace as the previous line 4) Pressing shift-tab removes the leading tab from the start of the current line, or N(=4) spaces from the start of the current line
No surprises, no auto-formatting, no having to go and reconfigure your text editor behaviour when you find random files with different conventions, no modelines etc. I see the huge depth of preferences in VS, and think it must be possible, but every time I come away less confident.
No, it's not too much to ask for, and visual studio supports that. But, it is too much to ask for as a default, because it's a terrible choice. The only reason somebody would want both #1 and #2 is if they put tabs and spaces into the same document. That's a terrible idea. Also #3 - why wouldn't I want my editor to auto indent the next line after an opening brace? I'm sorry, but the visual studio defaults are just better (and more popular) than your choices.
Obviously the defaults are going to be more popular than my non-default preference, and I would even agree that if there was no default, and people were forced to choose, they mostly wouldn't choose what I want.
However, if you can tell me how to get visual studio to do this, then I would be incredibly grateful.
In my opinion mixing spaces and tabs is completely fine because they are for different things. Tabs for indentation, and spaces for alignment.
Why no auto indent? Because the editor doesn't have enough information to do it correctly (e.g. perhaps you are about to paste some code which is already indented as you want it). I am not saying you should have the same preferences as me, but I am pretty happy with this behaviour, and perfectly ok with pressing tab after enter (or even pressing space 4 times - again, this is just my personal preference and I know that there was a time in my life when I would have looked at this with disgust).
So - how do I configure VS to do what I want?
However, if you can tell me how to get visual studio to do this, then I would be incredibly grateful.
In my opinion mixing spaces and tabs is completely fine because they are for different things. Tabs for indentation, and spaces for alignment.
Why no auto indent? Because the editor doesn't have enough information to do it correctly (e.g. perhaps you are about to paste some code which is already indented as you want it). I am not saying you should have the same preferences as me, but I am pretty happy with this behaviour, and perfectly ok with pressing tab after enter (or even pressing space 4 times - again, this is just my personal preference and I know that there was a time in my life when I would have looked at this with disgust).
So - how do I configure VS to do what I want?
Drop an appropriate .editorconfig file in the root of your solution. IIRC that will cover most of what you want to do. As to the format on paste.. you can explore the settings.
Generally speaking, I have VS Code configured how I want it and will use that over 95% of the time... even for C# projects.
Generally speaking, I have VS Code configured how I want it and will use that over 95% of the time... even for C# projects.
Just google "visual studio disable auto format." The first hit most likely provides exactly what you want.
https://stackoverflow.com/questions/737222/turn-off-auto-for...
You won't get much more help unless you describe what you've tried and why it didn't work for you. As far as I can tell the settings you're looking for aren't very hidden.
https://stackoverflow.com/questions/737222/turn-off-auto-for...
You won't get much more help unless you describe what you've tried and why it didn't work for you. As far as I can tell the settings you're looking for aren't very hidden.
When I tried last time (sorry, I don't have visual studio in front of me), I would get things like:
- Pressing enter results in just adding a newline, without copying the whitespace from the previous line OR - Pressing enter results in addine a newline, copying the whitespace, but replacing spaces with tabs on the new line
I guess if someone could once show how to make it so adding a newline to:
- Pressing enter results in just adding a newline, without copying the whitespace from the previous line OR - Pressing enter results in addine a newline, copying the whitespace, but replacing spaces with tabs on the new line
I guess if someone could once show how to make it so adding a newline to:
<tab><space><space><space><space>foo
<tab><space><space><space><space>foo
<tab><space><space><space><space>
<tab><space><space><space><space>foo
<tab><tab>#3 is stupid if it keeps inserting whitespace if you use git, its a horrible experience.
> The only reason somebody would want both #1 and #2 is if they put tabs and spaces into the same document. That's a terrible idea.
I’m not sure if the GP is asking for what you seem to be referring to. I thought of that request as the keys should insert the characters they stand for. Are you thinking only about multiple spaces used instead of a tab? Spaces are routinely used to increase readability in code. Even something as simple as comparisons in loops are more readable with spaces around the symbols. There are many other cases where spaces are used as spaces.
I’m not sure if the GP is asking for what you seem to be referring to. I thought of that request as the keys should insert the characters they stand for. Are you thinking only about multiple spaces used instead of a tab? Spaces are routinely used to increase readability in code. Even something as simple as comparisons in loops are more readable with spaces around the symbols. There are many other cases where spaces are used as spaces.
I think they understood. I'm happy with this as an example of a mix (and now prepared for the formatting to be eaten), which I believe would be seen as obscene by the commenter:
{
<tab>foo(arg1
<tab> ,arg2
<tab> );
}
{
<tab>bar(); /* Some comment
<tab> * across two lines */
}
LiveShare is by far the biggest developer moat Microsoft has keeping developers on MS tools, and it's shocking to me there are so few big companies out there that have been spurned into trying to advance open competition with live share, some how, any how.