3 ms·
It’s a little opposite of the topic, but am I the only one who’s noticed a considerable downturn in the productivity of VS? Yesterday I wanted to import “Micr
by jaabe 8y ago
It’s a little opposite of the topic, but am I the only one who’s noticed a considerable downturn in the productivity of VS?
Yesterday I wanted to import “Microsoft System Center Orchestrator Web Service” in a C# project, something which used to be a simple “add service reference”, only to be greeted by “we don’t import ODATA services this way anymore...” message and sent to some obscure framework for it. The first framework didn’t work with authentication and the second was so complicated that we ended up building it in Python instead of C#, using Visual Studio Code instead of Visual Studio.
That last bit seem to be a common thing. More and more we use VSC instead of VS, and last year it made us downgrade our enterprise subscription to VS because it didn’t seem worth it anymore.
Don’t get me wrong, it’s a decent article, I just didn’t value being reminded of TODOs as much as the actual time saving features which are slowly disappearing one by one. I mean, you can’t even build a non-empty project without drowning in bloat anymore. While it’s certainly rarely advisable to so in the first place, it can be useful with standard project bits on internal projects. We used to use MVC for that, now we use Django.
- pjmlp 8y agoI only use VSC for TypeScript and Rust related stuff. As someone that works mostly in a .NET full stack context across native and Web, VSC still has a lot of catchup regarding VS capabilities.
- jaabe 8y agoI agree, though maybe not with .Net core. It’s a personal preference, but I like the mix between VSC and the .Net Core CLI better than VS. .Net isn’t set in stone in our shop though. It’s been good to us for almost two decades, but recently it’s often in the damn way. Like with the orchestrator webservice. It’s Microsoft techs at both ends, yet it’s easier to build it in python, just doesn’t make sense.
- pjc50 8y agoVisual Studio anti-productivity feature: if you want to turn "convert warnings to errors" on, or change .NET framework level, in a large C# solution, you have to do it in each individual project. By hand or by writing a program to rewrite the XML. The whole "project" paradigm seems to have always been a little bit broken, rather than just having a clearer "sources" and "targets" definition.