.NET Core 2.0 was made publicly available on August 14. Besides .NET Core, .NET Standard 2.0 was released, the standard to which .NET Core 2.0 complies, as well as Entity Framework Core 2.0 and ASP.NET Core 2.0. Pretty cool, all have the same version number, but I’m sure this won’t go on forever! I almost forgot about NuGet, which also got a version bump, but alas, this was 4.3.
This was essentially an upgrade to the existing version 1.1, but it brought some breaking changes. It also increased the number of Linux operating systems supported, adding some popular distributions, as well as macOS.
All in all, version 2.0 was a good starting point for the next version, which is likely to be 2.1, and will build on some of the changes introduced by its predecessor. Let’s see what we can expect from it. In the meantime you can see what was available in version 2.0 in these two blog posts:
.NET Core 2.0 Changes – 4 Key Things to Know
and
.NET Core DLL Hell Is Here. Can .NET Core 2.0 Save Us?
According to the published roadmap, which may change over time, the next major version 2.1, should be out in the first quarter of 2018. We can probably expect pre-release versions by the end of this year, as usually happens.
There was talk of AppDomains coming back to .NET Core, we will probably see more APIs ported, and maybe we’ll have .NET Standard 2.1, bringing us closer and closer to a “full” .NET framework.
You can influence this roadmap, especially at this early stage, by creating a ticket in the dotnet/core repository with the roadmap label.
If you recall, Entity Framework Core 2.0 (as its predecessors) was received with mixed feelings. It has many good sides to it but was also missing some features that seasoned developers grew to like, such as lazy loading and grouping translation and support for ambient transactions. You’ll be pleased to know that at least the latter was on the checklist for version 2.1, and the former is a strong possibility.
As I said, version 2.1, will attempt to provide some popular features that were conspicuously missing from previous versions, such as grouping, ambient transactions, and eager fetching on derived types, but will also address two database systems, Cosmos DB (Azure-based, non-relational) and Oracle. Support for Oracle will likely be proof-of-concept, as it is expected that Oracle or other third-party vendors will be providing more robust solutions; After all, they are Microsoft competitors. As for Cosmos DB, it will be an important milestone, as Entity Framework Core was announced with great pomp as being NoSQL-friendly, something that hasn’t actually been the case: early support for Azure Table Storage was dropped before version 1.0 was out. Hopefully it will help other NoSQL providers to appear, as it definitely would be a good thing to be able to use the same familiar API to query disparate data stores.
New features will include the translation of LINQ GroupBy queries to SQL, something that was not easily achievable because EF Core does not yet support projection to unmapped classes. What is worse about the lack of it was that people wouldn’t even notice that it was missing. ode would compile and execute without problems, since all the grouping happened on the client-side. Just imagine if you wanted to do this over thousands of records, and you can’t understand why people are upset.
The .NET de facto standard for transactions is TransactionScope. I don’t expect most people using ADO.NET providers in 2017 to be explicitly creating transactions using BeginTransaction, since most of the time we just rely on ambient transactions supplied by TransactionScope. It can even promote them to distributed transactions transparently, if the need arises. It was missing from .NET Core essentially because it relied on the Microsoft Distributed Transaction Coordinator (MS DTC) service, but there are now other standards, such as X/Open, which are cross-platform. Anyway, it’s good to see it coming back, even if it only works on Windows.
[adinserter block=”33″]
Lazy loading is something that has a bad reputation among developers; people still want it, although I personally wouldn’t include it in my Top-5 wish list. Eager and explicit loading works fine and should be able to satisfy most common needs. One other related improvement that should be coming along is the ability to eager load collections of base types where we explicitly ask for a derived type.
A cool feature that may make it into 2.1 is type conversions. It will allow explicitly translating database columns into .NET types that are not obviously related, like translating a byte array into an image. It will also lay the foundation for spatial type support.
Another long-requested feature is data seeding as part of migrations. You may recall that database initializers were dropped in EF Core, and with it the capability to insert initial data when the database is created or updated. This will bring it back to database migrations.
It may also be possible to update an existing class model from the database; it is already possible to generate a model from scratch using an existing database, but this will allow the model to be updated from any possible schema modifications that may have taken place on the database. Quite handy!
Entity Framework Core 2.1 should support SQL Server’s Always Encrypted feature. This is complex stuff, as it will require changes to the SQL client library itself. In a nutshell, it will allow the encoding and decoding of encrypted database columns on the fly.
Microsoft will try to introduce column ordering for database creation and update. To be honest, most people usually need not care about this..
Also on the wish list are lifecycle hooks, including some events that existed in Entity Framework 6.x like EntityMaterialized and BeforeSaving. This will provide the basis for interception at the entity level, instead of the SQL or expression level. The actual details are not yet clear, so we need to wait and see.
It is also likely to be possible to map database views to entities, and maybe even stored procedures. This is in a very early stage so more details are expected in the near future.
Of course, Microsoft promises some optimizations in SQL generation and reuse, but it’s too early to guess what these are.
Of all these features, it seems to me that group by translation is the most important one, and I’d definitely like to see lifecycle hooks. Let’s just hope the team finds the time for all of these!
The next version of ASP.NET Core is still a bit uncertain. What we know for sure is that it will include SignalR, the real-time communication library, that was already available in pre-Core.
It is likely that it will also include the Health Check library, a set of primitives that can be used to assess the state of databases, web services and system resources.
WebHooks for ASP.NET Core has been idle for some time, but it is possible that it will be available together with the 2.1 release. More and more public sites (e.g., Google, Facebook, GitHub, JIRA) are offering webhooks, and developers have been asking for it in ASP.NET Core for some time, it’s good to see it addressed.
The future of NuGet includes package signing and package id (or prefix) reservation. The former will help people verify the identity of a package, which is always nice, and the latter will prevent package authors from saying they are someone else (like Microsoft, for example), it won’t allow anyone to release a package under the Microsoft.* name.
It was announced by Microsoft that Visual Studio 2017 (the current version) will be receiving minor updates every 6 weeks, and not just with major .NET/.NET Core version releases; it is a good thing, as we will be getting fixes more often than in the past. Servicing updates, for addressing a particular problem, will also be more frequent, up to once in a week. Read more in the official Microsoft statement here.
The next release of .NET Core is probably not as exciting as 2.0 was, but we need to get accustomed to it; after all, it just means that more and more of what we were used to is already here. It will bring some very useful features, such as SignalR to ASP.NET Core, and some well-needed improvements such as group by translation to EF Core. However, it is very early to know for sure since the scoping of items only just began. We’ll probably know more before the year’s end.
Stackify's APM tools are used by thousands of .NET, Java, PHP, Node.js, Python, & Ruby developers all over the world.
Explore Retrace's product features to learn more.
If you would like to be a guest contributor to the Stackify blog please reach out to [email protected]
