Comment on Microsoft is blocking Windows Customization Tools

• Thorry84@feddit.nl ⁨8⁩ ⁨months⁩ ago

  The biggest thing is the UI being completely different. I did use VS Code before, but only for my own projects, not stuff for work. So I did know how to use VS Code, but still it’s a major mental adjustment with everything being in a different place, features and shortcuts working differently etc.

  I really missed to Solution Explorer, which is probably my most used tool during work. But thankfully there is an excellent plugin which provides a Solution Explorer in VS Code. It’s a bit different from what I’m used to but it works just fine.

  Normally for casual profiling I’d use VS builtin tools. Only switching to something like DotMemory when really diving into optimization. This seems to be missing from VS Code. Probably there’s a plugin to fix that, but I want to keep the number of plugins to a minimum to prevent issues of plugins not being updated or having compatibility issues as much as possible. So now I switched to a different work flow for this to use tools like DotMemory sooner instead of the builtin stuff from VS.

  Resharper isn’t available for VS Code yet, but I don’t mind it. Some of my colleagues use it, but I prefer to do everything myself anyways and not use automated tools for code.

  I miss the Nuget package manager. Everything can be done using the terminal, both in VS and VS Code, which works the same. But the UI provided by the manager is so nice, it shows all the info you need, let’s you do almost anything with two clicks. I’ve checked out some plugins which are supposed to help with this, but have found none as good as the VS package manager. I’m proficient enough with the terminal it doesn’t really matter, but I still miss the manager and find myself checking different sources manually which used to be a lot more efficient. So I’ve taken an efficiency hit here, but I still can get the job done.

  Having everything done in the terminal panel takes some getting used to, where VS often launches different windows to get different kind of outputs. This is just something to get used to and could probably be changed in the settings, but I think it’s fine.

  In VS the project is launched as a separate process and then VS attaches itself to the process for debug and inspection purposes. In VS Code it’s a subprocess of the main editor process. This has some implications using third party tools for profiling for example. But I haven’t noticed anything going wrong. I think the way VS does it is better, but it’s probably fine? In theory an application could crash the whole VS Code process. But my code never crashes so I should be fine, right?

  Running and debugging is different but fine, with different profiles and debugging flags being managed from the UI and working perfectly. Publishing however is done only using the terminal, not the UI. Everything I need is available, but it took some figuring out how I need to do stuff using the terminal with regards to publishing. I’ve created a page on Confluence for myself with all the different stuff, which flags etc. It took some time but I think I’ve got everything figured out.

  For version management we already used a third party tool, so luckily no changes there. I have had to set some new ignores, but other than that no changes.

  Creating new projects is something I haven’t figured out how to do. For work I only ever work in existing projects that have been around for ages. I don’t know how easy it would be to create something new with all the required files and parameters so my colleagues can also use it. The other day I wanted to quickly check something in an empty project and I had to reach for VS again (for shame). I need to put in some time figuring this out in VS. It’s probably not complicated, but as I said I wanted to check something quickly so I didn’t have the time.

  There are probably a thousand little things I have changed or have to get used to. But these are the main ones.

  source