Because they need developers more than developers need them. If they become as dominant as Apple and Google in their respective spaces, expect your experience to degrade.
Google has never been about the developer experience, and is quite hostile to developers even when they need them. (See, e.g., Stadia.)
The only reason people went there usually was for the money and once they got enough to follow their passion, they left because none of them were passionate about Microsoft.
Microsoft's C++ IDE and debugger are the gold standard for productivity and ease of use - everyone who writes native applications for Windows uses Visual Studio. You can try it out for free and the price per developer is very reasonable if you want to publish a paid product.
Google's C++ IDE and debugger are nonexistent. Whatever they've built is kept inside the Googleplex never to see the light of day. From time to time we see the occasional free software reimplementation of some facet of the beast (e.g. Kythe) but I haven't seen something catch on.
In fact, the biggest contributors to developer productivity on Linux have been Microsoft (with Visual Studio Code and the lsp protocol) and Apple (investing in clang led to the development of advanced C++ indexers which were impossible to write using gcc due to Stallman making a conscious decision to not allow it)
Of course there is a good reason for this - Microsoft and Apple make platforms. The easier they make software development, the more developers they get, which leads to more software being written, which leads to more users, which results in profit. Google on the other hand doesn't win by making development easy for others. They're themselves a third party and other developers are competition rather than partners. For Microsoft, the existence of developers outside the company using Microsoft's development tools to create software for Microsoft's platform is a win. For Google, the best case scenario is there being no developers outside Google.
The navigation is nearly unusable. Don't focus the project navigation on a tree browser if you're not going to integrate it into the rest of the navigation workflow.
NuGet regularly fails silently to restore packages.
It uses a virtual filesystem that usually maps 1:1 to the actual project folder.. except files created outside of VS are completely invisible to it, unless manually added to the project.
The project/solution files are very verbose and aren't designed to be edited by humans.
The migration path from .NET Framework to .NET Core seems to be "create a new project, copy the files over manually, and copy over your old settings one by one".
Some of these have been fixed for new projects, but there is no option to migrate to the new structure. Except, again, starting over with a new one.
You are talking about the biggest architecture change of. Net in 30 years ( going cross platform) and they are still going to support VB 6, WPF,..
Visual studio is actually a very robust IDE. The issue you are mentioning is .net framework project files and if you copy files within or to Visual Studio it will be added. .net framework only wants to add files you want to deploy ( not perfect, but okay).
For migrating to. Net standard 2.0, remove assemblyinfo.cs and change the. Csproj file. You should manually add the Nugget packages again or change it to the new structure. The biggest issue is entity framework though, in a lot of projects. From. Net standard to . Net core is a lot easier.
Seems pretty reasonable to me, updating other things ( eg. Android) have caused more issues than this.
Ps. Navigating is mostly f12 of control+f12
The project/solution files are bog standard xml, and well documented, but in general you shouldn't need to touch them.
The migration from framework to core 3.0 is now very simple thanks to xaml support, but it used to be a huge hassle. You can literally just edit the tags in your csproj/fsproj/etc to enable different target frameworks, or you can use the ui [0], and then you'll need to do a nuget reinstall. One command [1].
As for running into bugs, they built bug/feature requests into the visual studio 2019 ide, or you can access it via the website [2]. They are usually very responsive, typically something within a couple of days.
[0] https://stackoverflow.com/questions/57334018/visual-studio-2...
[1] open package manager console, type 'update-package -reinstall'.
Project files are "bog standard" XML (except for all the weird magic, like variable resolution and conditionals), but solution files are some unholy VB-like abomination.
But regardless, that doesn't help much when the schema is clearly not designed for human editing (incredibly verbose, UUIDs everywhere for references, etc).
> The migration from framework to core 3.0 is now very simple thanks to xaml support, but it used to be a huge hassle.
No idea how a GUI description language is supposed to help you here.
> You can literally just edit the tags in your csproj/fsproj/etc to enable different target frameworks
Didn't work for me.
> or you can use the ui [0], and then you'll need to do a nuget reinstall. One command [1].
Keep in mind that that command is free to update dependencies as it feels like.
At the very least you could have given an example of an IDE that you consider is better. You were just talking out of your arse.
If you're going to pick a mode of navigation then at least commit to it. It's subjective whether or not any particular choice is good. The quality of the implementation, not so much.
> 2. Downright bullshit. You are starting to whine.
Sorry for wanting a package manager to... manage packages, I guess.
Or maybe it's configured wrong? I guess it's too much to expect two Microsoft tools to work well together..
> 3. Subjective but far from something that makes the IDE a "piece of crap"
Do you never edit your project files from outside the IDE?
> 4. You are starying to sound like you are in the wrong industry.
Compare a typical SBT build definition[0] or Cargo.toml[1] to a typical VS solution[2] or project[3]. Which would you feel the most confident about when modifying by hand?
(Hint: For me, it's definitely not the one that is full of autogenerated cartesian products.)
> 5. No. Change the .csproj and drop the AssemblyInfo.cs usually work for something that can actually be migrated.
So why couldn't Microsoft include a tool for that migration? That seems like table stakes for such a migration project. We're not exactly talking about 2to3[4] or rustfix[5] here...
> If you expect any project that targeted Windows to just migrate to cross platform using a NNF you are an idiot.
Amazing how Microsoft are completely unable to even get close to what the Wine and Mono people did years ago.
> At the very least you could have given an example of an IDE that you consider is better. You were just talking out of your arse.
Throw a dart and you'll find something. If you want the out-of-the-box live-in-your-IDE experience then JetBrains' stuff is miles better than VS. Personally I moved on to Spacemacs[6] after a few years each of VS and IntelliJ.
[0]: https://gitlab.com/teozkr/what-should-i-sing/blob/master/bui...
[1]: https://gitlab.com/teozkr/scankiosk/blob/master/scankiosk-ui...
[2]: https://github.com/getsentry/raven-csharp/blob/develop/src/S...
[3]: https://github.com/getsentry/raven-csharp/blob/develop/src/a...
[4]: https://docs.python.org/3.8/library/2to3.html
I've had some issues during Firefox extension reviews too, and Mozilla employees have usually changed their opinion after feedback. When they've made a mistake, sometimes they said they were sorry, which was a decent thing to do and it felt right. They talked and acted like human beings whom are capable of compassion and reasoning.