4 ms·

NET Core 2.1 Roadmap

36 points by benaadams 9y ago

nwah1 9y ago
Awesome. Lazy Loading for EF is probably the most requested feature there. I'm wondering how Kestrel is doing, and if it will finally be available as a freestanding web server, not behind a reverse proxy. Looks like HTTP/2 support is delayed until at least 2.2.
- dmarlow 9y ago
  Is lazy loading really that widely used? I used it once and it led to all sorts of issues unless I managed everything myself. I much prefer to have it off and rely on explicitly getting what I need.
  - nwah1 9y ago
    I notice for complicated apps you often want to turn it off, but development time probably is slightly faster on simple apps with lazy loading and is the previous default. I would probably want eager loading to be the default, but lazy would be useful for porting old code at minimum.
- deleted 9y ago
  [deleted]
- DamianEdwards 9y ago
  Limits and timeouts were added to Kestrel in 2.0 that enable it to be supported for use as an Internet facing web server (we made that announcement then too). Reverse proxies are still advised for defense in depth of course.
- benaadams 9y ago
  Kestrel was "more suitable as an Internet-facing server" at 2.0 https://blogs.msdn.microsoft.com/webdev/2017/08/25/asp-net-core-2-0-features-1/ https://blogs.msdn.microsoft.com/webdev/2017/08/25/asp-net-c... Section: Kestrel Hardening
polskibus 9y ago
Still no production-ready ODBC in .NET Core? How is one supposed to work with database engines in a standard way? Java is miles ahead by just sticking to JDBC. Microsoft first moved off ODBC towards OLE DB only to ditch it some years later. Working with data and being able to connect to a plethora of data sources is essential to a platform success. .NET Core won't be treated as a serious cross-platform toolkit if it won't offer a reliable, interoperable interface.
- benaadams 9y ago
  System.Data.Odbc? https://www.nuget.org/packages/System.Data.Odbc/ https://www.nuget.org/packages/System.Data.Odbc/
  - polskibus 9y ago
    It's been in preview for ages. I hope with .NC 2.1 it will be production ready and well tested on all platforms.
- da_chicken 9y ago
  .NET Core didn't have DataSet/Table/View until v2.0. I'm still boggled by the idea that they think those are legacy (https://github.com/dotnet/corefx/issues/1039#issuecomment-77476363 https://github.com/dotnet/corefx/issues/1039#issuecomment-77...) and that everybody will just use entity framework for everything.
  - polskibus 9y ago
    I wonder how did they implement Power BI? Surely by implementing it, they must've realized that a robust set of fairly low level interoperable APIs is essential for working with data. EF is often too slow, that's why Dapper et al are used instead.
  - nwah1 9y ago
    Are you concerned about the overhead of EF? Porting old code? If you want db-specific features, you could always call a stored proc. EF code first is very pleasant to develop with, and when starting a new project in .NET Core, I'd always prefer that.
yokohummer7 9y ago
> Build-time performance is much improved in .NET Core 2.1, particularly for incremental build. These improvements apply to both dotnet build on the commandline and to builds in Visual Studio. It is good to see some improvements. Currently, `dotnet build` takes at least 3 seconds to compile a simple hello world project on my system, even when the source code isn't changed at all. At first I thought I did something wrong, but no, others were suffering from this too.[1][2] This occurs because every `dotnet build` run tries to resolve the dependencies and inspect the file structure to see if any changes are made. And for some reason those operations are dog slow. Visual Studio doesn't have this problem, as it knows the file structure and the dependencies beforehand, so it can determine whether there should be a recompilation easily. I wanted to use VS too but it was too slow for my tiny laptop, so I'm stuck with VS Code. I hope the improvements are big enough that I can reevaluate using .NET Core again. The build time was a huge obstacle to my iteration cycle, so I had to use TypeScript in my previous project. I sincerely want to code my backends in C#. [1] https://github.com/dotnet/cli/issues/5918 https://github.com/dotnet/cli/issues/5918 [2] https://github.com/dotnet/cli/issues/7610 https://github.com/dotnet/cli/issues/7610

36 points by benaadams 9y ago

Awesome. Lazy Loading for EF is probably the most requested feature there. I'm wondering how Kestrel is doing, and if it will finally be available as a freestanding web server, not behind a reverse proxy. Looks like HTTP/2 support is delayed until at least 2.2.

dmarlow 9y ago
Is lazy loading really that widely used? I used it once and it led to all sorts of issues unless I managed everything myself. I much prefer to have it off and rely on explicitly getting what I need.
- nwah1 9y ago
  I notice for complicated apps you often want to turn it off, but development time probably is slightly faster on simple apps with lazy loading and is the previous default. I would probably want eager loading to be the default, but lazy would be useful for porting old code at minimum.
deleted 9y ago
[deleted]
DamianEdwards 9y ago
Limits and timeouts were added to Kestrel in 2.0 that enable it to be supported for use as an Internet facing web server (we made that announcement then too). Reverse proxies are still advised for defense in depth of course.
benaadams 9y ago
Kestrel was "more suitable as an Internet-facing server" at 2.0 https://blogs.msdn.microsoft.com/webdev/2017/08/25/asp-net-core-2-0-features-1/ https://blogs.msdn.microsoft.com/webdev/2017/08/25/asp-net-c... Section: Kestrel Hardening

polskibus 9y ago

Still no production-ready ODBC in .NET Core? How is one supposed to work with database engines in a standard way? Java is miles ahead by just sticking to JDBC. Microsoft first moved off ODBC towards OLE DB only to ditch it some years later. Working with data and being able to connect to a plethora of data sources is essential to a platform success. .NET Core won't be treated as a serious cross-platform toolkit if it won't offer a reliable, interoperable interface.

benaadams 9y ago
System.Data.Odbc? https://www.nuget.org/packages/System.Data.Odbc/ https://www.nuget.org/packages/System.Data.Odbc/
- polskibus 9y ago
  It's been in preview for ages. I hope with .NC 2.1 it will be production ready and well tested on all platforms.
da_chicken 9y ago
.NET Core didn't have DataSet/Table/View until v2.0. I'm still boggled by the idea that they think those are legacy (https://github.com/dotnet/corefx/issues/1039#issuecomment-77476363 https://github.com/dotnet/corefx/issues/1039#issuecomment-77...) and that everybody will just use entity framework for everything.
- polskibus 9y ago
  I wonder how did they implement Power BI? Surely by implementing it, they must've realized that a robust set of fairly low level interoperable APIs is essential for working with data. EF is often too slow, that's why Dapper et al are used instead.
- nwah1 9y ago
  Are you concerned about the overhead of EF? Porting old code? If you want db-specific features, you could always call a stored proc. EF code first is very pleasant to develop with, and when starting a new project in .NET Core, I'd always prefer that.

yokohummer7 9y ago

> Build-time performance is much improved in .NET Core 2.1, particularly for incremental build. These improvements apply to both dotnet build on the commandline and to builds in Visual Studio. It is good to see some improvements. Currently, `dotnet build` takes at least 3 seconds to compile a simple hello world project on my system, even when the source code isn't changed at all. At first I thought I did something wrong, but no, others were suffering from this too.[1][2] This occurs because every `dotnet build` run tries to resolve the dependencies and inspect the file structure to see if any changes are made. And for some reason those operations are dog slow. Visual Studio doesn't have this problem, as it knows the file structure and the dependencies beforehand, so it can determine whether there should be a recompilation easily. I wanted to use VS too but it was too slow for my tiny laptop, so I'm stuck with VS Code. I hope the improvements are big enough that I can reevaluate using .NET Core again. The build time was a huge obstacle to my iteration cycle, so I had to use TypeScript in my previous project. I sincerely want to code my backends in C#. [1] https://github.com/dotnet/cli/issues/5918 https://github.com/dotnet/cli/issues/5918 [2] https://github.com/dotnet/cli/issues/7610 https://github.com/dotnet/cli/issues/7610