4 ms·

i've been using .net for years (since 1.x), before was using Java... i think you should consider the very good documentation (MSDN on all) the main drawback, IM

i've been using .net for years (since 1.x), before was using Java... i think you should consider the very good documentation (MSDN on all) the main drawback, IMHO, is when you try to go out of the MS PATH you could go crazy (eg using different DBMS different than SQL Server or using different implementation patterns).. this applies to medium-big sized project not for simple ones... Hope the .NET CORE will solve this. Moreover, Visual Studio is great even if a bit buggy. hope this helps

brightball 10y ago
So is the implication that using non-.NET stack pieces creates headaches? Ex - PostgreSQL with the T-SQL plugin?
- WorldMaker 10y ago
  It definitely has been the case that .NET very nicely golden pathed the Microsoft solutions and working with non-Microsoft options in the same space was quite a bit harder and a lot less golden. Some of that was intentional (if you are using .NET, you clearly should buy a MS SQL Server license), and some of that was simply that .NET as a culture didn't embrace open source all that much until recently. Most .NET developers traditionally have been in the sort of big-E Enterprise development land where "use what Microsoft sells because we can trust it" and "don't publish anything to open source" have long gone hand in hand. Both of that definitely seems to be shifting for the better. There are a lot more .NET developers with at least one foot in open source these days, including and especially Microsoft as almost the entirety of .NET itself is now open source. You can also see that the Developer Division at Microsoft is less marketing driven and sees less need to pressure people to stay on the Microsoft sold golden paths and is increasingly happy to help pave over some of the cow paths and make working with non-Microsoft solutions easier than ever before. Obviously, still a lot of work to do on that front, of course, but if you look at EF Core, for one example, you see much more embrasure of supporting the Microsoft option and the non-Microsoft options. Before EF Core it was hard to imagine seeing PostgreSQL support or SQLite support in EF.

brightball 10y ago

So is the implication that using non-.NET stack pieces creates headaches? Ex - PostgreSQL with the T-SQL plugin?

WorldMaker 10y ago
It definitely has been the case that .NET very nicely golden pathed the Microsoft solutions and working with non-Microsoft options in the same space was quite a bit harder and a lot less golden. Some of that was intentional (if you are using .NET, you clearly should buy a MS SQL Server license), and some of that was simply that .NET as a culture didn't embrace open source all that much until recently. Most .NET developers traditionally have been in the sort of big-E Enterprise development land where "use what Microsoft sells because we can trust it" and "don't publish anything to open source" have long gone hand in hand. Both of that definitely seems to be shifting for the better. There are a lot more .NET developers with at least one foot in open source these days, including and especially Microsoft as almost the entirety of .NET itself is now open source. You can also see that the Developer Division at Microsoft is less marketing driven and sees less need to pressure people to stay on the Microsoft sold golden paths and is increasingly happy to help pave over some of the cow paths and make working with non-Microsoft solutions easier than ever before. Obviously, still a lot of work to do on that front, of course, but if you look at EF Core, for one example, you see much more embrasure of supporting the Microsoft option and the non-Microsoft options. Before EF Core it was hard to imagine seeing PostgreSQL support or SQLite support in EF.