4 ms·

One difference that stands out to me about Microsoft vs Google. Both are very heavy C++ shops. Both have invested in developing tools for enhancing developer pr

by Asooka 7y ago

One difference that stands out to me about Microsoft vs Google. Both are very heavy C++ shops. Both have invested in developing tools for enhancing developer productivity on their respective platforms (Windows and Linux). Yes, Linux is not a Google product (thank god) but it is what they build on. 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.

Nullabillity 7y ago
Have you actually tried to use Visual Studio? It's an unusable piece of crap. 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.
- NicoJuicy 7y ago
  Euh, lol. 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
- eyegor 7y ago
  As someone who uses visual studio + code literally every day, I'm not sure what you're referring to with most of these complaints. 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-2019-select-framework-version-for-net-core-class-library-projec https://stackoverflow.com/questions/57334018/visual-studio-2... [1] open package manager console, type 'update-package -reinstall'. [2] https://developercommunity.visualstudio.com https://developercommunity.visualstudio.com
  - Nullabillity 7y ago
    > The project/solution files are bog standard xml, and well documented, but in general you shouldn't need to touch them. 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.

by Asooka 7y ago

Nullabillity 7y ago

Have you actually tried to use Visual Studio? It's an unusable piece of crap. 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.

NicoJuicy 7y ago
Euh, lol. 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
eyegor 7y ago
As someone who uses visual studio + code literally every day, I'm not sure what you're referring to with most of these complaints. 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-2019-select-framework-version-for-net-core-class-library-projec https://stackoverflow.com/questions/57334018/visual-studio-2... [1] open package manager console, type 'update-package -reinstall'. [2] https://developercommunity.visualstudio.com https://developercommunity.visualstudio.com
- Nullabillity 7y ago
  > The project/solution files are bog standard xml, and well documented, but in general you shouldn't need to touch them. 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.