241–250 of 312 posts
Earlier quoted context omitted.
It's the only practical way to do cross-platform .NET Core development.
If that's true, then I'd recommend not using either .NET or VSCode if cross platform matters to you. Historically speaking, Microsoft will break compatibility when it suits them.
Earlier quoted context omitted.
Ever heard of Project Centennial? Or the fact that all new APIs are mostly UWP only?
Yes, and how's that coming along? Is this "project" supposed to make those old clunky non touch optimized windows desktop apps suddenly usable on a tablet? I don't think so. Instead its going to be another failure just like Project Astoria and Project Islandwood.
Earlier quoted context omitted.
Vscode is an IDE. It integrates all your development into one environment. It comes with support for version control, code editing, task running, and debugging all from one application.
An IDE is so much more. For instance, refactoring features. Even Microsoft defines VSCode as a "code editor" and not an IDE.
I wonder what someone coming from an earlier era would have to say on that...
Earlier quoted context omitted.
Vscode is an IDE. It integrates all your development into one environment. It comes with support for version control, code editing, task running, and debugging all from one application.
An IDE is so much more. For instance, refactoring features. Even Microsoft defines VSCode as a "code editor" and not an IDE.
Earlier quoted context omitted.
Yes, building works well. But how do you run your application? (To be clear I'm asking what workflow users use personally, since it seems like nobody else has this issue.)
For me, I build on the command line, because I have a funky build process, and then when I want to debug it I just press the 'debug' button. There's a big JSON file with the debug configurations, and a drop-down to allow you to select which one is active. Each gdb debug configuration lets you specify the usual binary path and command line arguments, plus a whole lot of other configuration I haven't looked at. I haven…
If you attach or launch more than one process, that's where they will appear also, as top-level tree nodes.
I am surprised at the amount of semi-negative comments here. Yes, some features are yet to be implemented, (it's still a fairly young project and you can always follow GitHub issues on progress), but for an Electron app, it's surprisingly fast and capable. The Microsoft-developed Go plugin makes it the best Go IDE out there, the devs, (Ramya Rao etc.) are super responsive and really trying to resolve issues quickly.…
How does it compare to LiteIDE?
Earlier quoted context omitted.
Nothing in VS Code is terribly web specific. I've been using it for C++ for which it works swimmingly.
The personal preferences file includes several defaults for S/CSS, HTML, JS and TS, and it has a lot of Typescript stuff out of the box, some node stuff.
Earlier quoted context omitted.
> the experience of using PS was superior to that of bash As a Linux dweller, I'm genuinely curious about this one. I've found PS inferior in just about any use case.
PS is great if everything you are dealing with is built for the .NET ecosystem. It's less great otherwise. This makes it often great for working on Windows, and definitely great for working with Windows and other MS software that is designed for the .NET/PS world.
Earlier quoted context omitted.
On that note if you are a .NET developer you owe yourself to learn PS and how to write cmdlets, it's such a powerful and easy way to expose a CLI for your .NET app compared to stdio and command line arguments parsing - it's incredibly powerful and trivial to do. Unfortunately most .NET devs are programmers who grew up with VB, RAD and GUI tools they don't understand the value of exposing UNIX like small functionality…
I'm a .net developer, I still install cygwin/bash on my computer because I can write stuff quicker and better. PS get's incredibly verbose for anything non trivial. I learned powershell long before bash too.
Sure, perhaps they're not as compact as some of the incredibly information-dense perl scripts that people come up with.
I'd wager though that it's easier to understand what a random powershell script is doing than a random perl or bash script that pipes output throgh a dozen utilities.