I've found it the most practical to keep each project in their own separate repository, and then create an independent repo for storing the Workspace files. What I usually do is define all of the individual launch configurations for each project within my Workspace, and then use compound launch configurations at the Workspace level to call many of the project launch configs simultaneously. Since the Workspace file can access launch configurations defined on the project level as well, things are very nice and modular to work with. The same configuration format can be used within the Workspace file to define the behavior for launching multiple projects at once. Within a VS Code project, you can define launch configurations and other tasks for each project within the. In this case, they're called "multi-root" workspaces. Instead, VS Code uses Workspaces which can contain groups of projects similar to Solutions. Solutions are specific to Visual Studio and have no place in VS Code. You're going to need Microsoft's C# Extension to handle everything C# related within VS Code, including attaching to processes and debugging. Not because I can set my VS Code to be Hatsune Miku themed. Also I don't really like being forced to develop on Windows.
I'll admit that this type of automation is extremely useful for getting started with a new stack, but these days I'd rather sacrifice a bit of time dealing with configurations if it means I'm given more control. For instance, when you realize that Visual Studio is using its own version of Angular stored somewhere in your system files, and that Microsoft decided to make this a hassle to change. However, this type of automation becomes very frustrating when things break down. It has an enormous set of features and handles mountains of configurations and commands "behind the scenes," without forcing the developer to waste time dealing with these things. I've been using Visual Studio for nearly a decade and think it is probably the most powerful IDE available.
0 kommentar(er)
