If I were a .NET web developer
... I would be excited about this part "debugging Alpine ASP.NET Core". Turns out that running ASP.NET core on Alpine is a thing that Microsoft actually wants developers to do!
Developers rejoice! The second preview of Visual Studio 2019 is upon us and contains all manner of goodies for those brave enough to venture into the not-for-production environment. Little has changed on the IDE front which, to be frank, is no bad thing. The increase in coding space alone made the first preview a pleasant …
Visual Studio 2017 takes less than 10 seconds to start on my aging desktop machine. It's quite possible the SSD system drive helps there, but if you don't have one of those already you should re-evaluate your life choices. ;). Seriously though, it's possible you have an extension that's taking more time than it should to organise itself and start in a timely manner.
"Visual Studio 2017 takes less than 10 seconds to start on my aging desktop machine. It's quite possible the SSD system drive helps there"
It takes about 10s to start, and another 20s to actually be usable (i.e. news, recent projects, etc, to be populated) on my work-issued laptop (i7-4600U, 16GB DDR3, & Samsung 850 EVO).
Ah, I always hide the news section in the start page - it's not like I'm going to ever read it. :)
It's strange your recent projects list takes so long to populate though. My projects aren't even on the SSD and I rarely notice having to wait for them to appear.
A cold boot on my laptop takes about six seconds to start Visual Studio and another second and a half to get the start page ready for use. My desktop machine is ready for use in about three seconds.
Thinking about it though, I did have a similar issue some time last year where the whole thing would freeze on start up for about 10-15 seconds. I think that might have been related to validating the account for the licence. I can't remember though whether I changed some setting somewhere, or whether the problem disappeared when I upgraded Visual Studio (I'm currently on 15.9.4).
It launches in about 10 seconds but then spends another half a minute to a minute loading the solution all the while trying to kid on that it's ready for work. No wait cursor, see? Ah but just you try and actually do something and suddenly you'll find your clicks being ignored or 'hang on a moment' windows appearing.
VS startup is like some vindictive, masochistic tease. It'd be better if it just left a 'please wait' message up until it was done. Instead we have to play the guessing game of prodding it at random intervals until it finally starts to respond in a useful way.
Yeh I agree that sounds like a set up issue. I've got a 60 project solution with a mix of WPF, WebAPI, Console and web projects, along with unit tests and it's fully loaded in ~10s. Quite impressive really compared to other IDEs like Rad Studio and Eclipse which I also use from time to time. Granted I have a 9900k and 970 Evo but it's not much slower on my laptop or other devices, maybe around an additional 5s, certainly not enough that I notice it as a bad thing.
My list is pretty long...
For starters, I'd like them to stop it with the 2D FLATTY McFLATFACE, the VB-style "properties" stuff for class wizard and dialog editing that they've done since 2000-ish [which requires removing my mouse hand from the keyboard WAY too often], LESS centricity on C-pound, and _ALSO_ fix MFC so it's not so bloaty when you static link. Too many un-needed "features" are linked in ALL of the time, last I checked. And it seemed to be very difficult to remove it with compile options. I tried, yeah.
And it should be easier to do these things:
a) COMPLETELY exclude ".Not" from your project
b) static link runtime
c) static link class libraries
I don't like flipping all of the parameters on and off for EVERY STINKING PROJECT and so a pre-set "these are my project defaults" would be nice. Maybe it exists already, I dunno, just want to see something more reasonable than having to spend 10+ minutes "fixing" it, EVERY time.
What I've disliked about VS started with the 'The Metro' stuff. I've used the 2010 version for ALL windows development for quite a while now. It's "not changing" which is better than 'change for the sake of change' every time. I do NOT like the 2D FLATTY and am *NOT* going to do any stupid "the Metro" or "UWP" [CR]app. So the _OLDER_ one is superior as far as THAT goes.
In any case, I'm not pleased if I can't easily turn my project into a 'Makefile' version, and build without any special IDE nonsense. It's getting harder and harder to do that with Microsoft's tools.
It's a nice gesture, but would be totally unnecessary if each tool window didn't have a title bar, a toolbar, and a row of tabs at the bottom. The first versions of Visual Studio (and Developer Studio before) had way more space for code and ancilliary windows than the current versions have.
They could give some of us even more space if they tried a bit harder.
But it's contentious. There's clearly a lot of people don't like the removal of the title bar.
Yeah, I don't care about the title/menu bar. I already have the tools I need appended to the menu bar. As long as they don't break my ability to keep my current layout in that respect I don't care.
But I voted and commented on the linked issue. Thanks for that - finding stuff in the feedback app is next to impossible.
Thanks for that - finding stuff in the feedback app is next to impossible.
Ain't that the truth. I've used some unpleasant forums in my time but the VS community one is lousy.
It is possible to get good responses from the MS guys on there though which is why I keep reporting stuff. Just a pity that my most recent report can be summed up as 'P2 buggered up mobile development' :-/
I only use the 2010 version for C++ on windows these days. And I _REFUSE_ to use C-pound. Yuck. Just Yuck.
I'm moderately satisfied with MFC on windows for a couple of reasons, assuming that it's statically linked (runtime AND MFC) and has _NO_ ".Not" dependencies. one is that I'm familiar with it, and the coding stuff I was doing in the 90's still works with it, more or less. The other is that wxWidgets can be [with some difficulty] ported from an MFC applicationt to run cross-platform.
Why does the blood run cold when MS gets designery on VS? Could it be because of previous monstrous screwups in that department? I'm prepared to give the latest version I have (2017) credit for correcting most of the mistakes of the past, but why did those mistakes have to happen in the first place? That whole bland, blander, blandest choice of color themes they gave us. The micro-thin borders on window panes that took a steady hand just to grab them to resize the window. Sometimes I wonder if MS uses VS as the elimination game for UX designers before letting them near the Office products. If so, it isn't working out well for anyone, including those poor drones who use Office.
If Microsoft put half the effort into creating decent help docs that they put into making their products look kyewl, we'd all be a lot happier.