.NET Core 3
.NET Core was presented by Microsoft in 2016, but its 1.x versions had limited set of features comparing to Full .NET Framework. Since then .NET Core has been drastically improved. .NET Core 2.0 has a significant part of Full .NET Framework features and includes new functionality and significant performance optimizations.
This year, a new .NET Core 3 is coming. It is currently available as .NET Core 3.0 Preview 9, and despite its preview status, Microsoft officially recommends it to full production use. Besides, Microsoft sends some signals that the development of Full .NET Framework is frozen, its 4.8 version will be the last, and will receive mostly fixes after .NET Core 3.0 release, and the latter will become the recommended platform for all the new applications immediately after release. Meanwhile the Porting desktop apps to .NET Core and Port your code from .NET Framework to .NET Core articles are posted on Microsoft resources.
.NET Core 3 has very many new features, and it’s impossible to describe them in a blog article. You can start learning about them by reading the What’s new in .NET Core 3.0 article. As for performance improvements, you can read the following articles about them:
- Performance Improvements in .NET Core vs .NET Framework 4.7
- Performance Improvements in .NET Core 2.1
- Performance Improvements in .NET Core 3.0
Devart’s ADO.NET providers for Oracle, MySQL, PostgreSQL, and SQLite support all the .NET Core versions: previous 1.x and 2.x releases as well as the new .NET Core 3.0, and can be used on Windows, Linux and Mac OS. They are available as the following NuGet packages:
We are currently studying, which features to add to our providers for .NET Core 3. The features will be added based on feedback of our users, so please visit our forum or feedback pages and post your feature requests there.
Entity Framework 6.3
Entity Framework 6 users stood aside of this rapid .NET Core development spurt. Till recently, they only could migrate to .NET Core by migrating to Entity Framework Core at the same time. While Entity Framework Core has a decent degree of compatibility with classic Entity Framework 6, some of Entity Framework 6 features are still not implemented, and some have significant differences in behavior and implementation (see the Entity Framework Core and Entity Framework 6 comparison.
Besides, fast .NET Core development causes a significant number of growth issues when updates cause some previous features to stop working (see here). This holds migration of existing Entity Framework 6 projects to Entity Framework Core. Besides, functionality differences make some of the developers choose familiar Entity Framework 6 for new projects too.
The following diagram shows the NuGet.org download statistics and demonstrates that despite rapid growth of interest to Entity Framework Core, Entity Framework 6 is still highly popular for use in new projects, and there are no signs of growth recession.
Entity Framework 6.3 is a real game-changer, because it now supports .NET Core 3 and opens a way to both migrate existing Entity Framework Classic applications and create new ones, using .NET Core 3 with EF 6.3. Entity Framework 6.3 is currently at the pre-release stage of development (Preview 9), but it is already fully-functional and can be used for migration to .NET Core 3.
With the appearance of Entity Framework 6.3, we announce the first major addition to .NET Core related features of our ADO.NET providers for .NET Core 3: Entity Framework 6.3 support in our new NuGet packages:
These NuGet packages contain .NET Standard 2.1 assemblies, compatible with .NET Core 3 runtime.
We tried hard to maintain all the existing features in order to ease migration of existing projects to Entity Framework 6.3 and .NET Core 3. There are, however, some differences, described below, that must be considered during migration.
Provider Registration for Entity Framework 6.3
Registering an Entity Framework provider is different for Entity Framework 6.0 – 6.2 and for Entity Framework 6.3. Entity Framework 6.0 – 6.2 allows registering Entity Framework provider in the app.config file of the application. Here is an example for dotConnect for Oracle:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<!-- For more information on Entity Framework configuration, visit http://go.microsoft.com/fwlink/?LinkID=237468 -->
<section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
</configSections>
<entityFramework>
<providers>
<provider invariantName="Devart.Data.Oracle" type="Devart.Data.Oracle.Entity.OracleEntityProviderServices, Devart.Data.Oracle.Entity.EF6, Version=9.7.805.0, Culture=neutral, PublicKeyToken=09af7300eec23701" >
<migrationSqlGenerator type="Devart.Data.Oracle.Entity.Migrations.OracleEntityMigrationSqlGenerator, Devart.Data.Oracle.Entity.EF6, Version=9.7.805.0, Culture=neutral, PublicKeyToken=09af7300eec23701" />
</provider>
</providers>
</entityFramework>
<system.data>
<DbProviderFactories>
<remove invariant="Devart.Data.Oracle" />
<add name="dotConnect for Oracle" invariant="Devart.Data.Oracle" description="Devart dotConnect for Oracle"
type="Devart.Data.Oracle.OracleProviderFactory, Devart.Data.Oracle, Version=9.7.805.0, Culture=neutral, PublicKeyToken=09af7300eec23701" />
</DbProviderFactories>
</system.data>
</configuration>
Entity Framework 6.3 does not use such registration. Instead it uses two code based approaches:
- The first one is to use the DbConfigurationType attribute. It suits only for DbContext. Here is an example for dotConnect for Oracle:
[DbConfigurationType(typeof(Devart.Data.Oracle.Entity.OracleEntityProviderServicesConfiguration))] public class MyContext : DbContext { // ... } - The second way is to use the static SetConfiguration method of the DbConfiguration class. It can be used both with DbContext and ObjectContext. Here is an example for dotConnect for Oracle:
public class MyContext: ObjectContext { static MyContext() { DbConfiguration.SetConfiguration(new Devart.Data.Oracle.Entity.OracleEntityProviderServicesConfiguration()); } // ... }
Both of the above examples use the OracleEntityProviderServicesConfiguration class that suites for most users. All our Entity Framework 6.3 providers have a similar class:
- Devart.Data.Oracle.Entity.OracleEntityProviderServicesConfiguration (dotConnect for Oracle)
- Devart.Data.MySql.Entity.MySqlEntityProviderServicesConfiguration (dotConnect for MySQL)
- Devart.Data.PostgreSql.Entity.PgSqlEntityProviderServicesConfiguration (dotConnect for PostgreSQL)
- Devart.Data.SQLite.Entity.SQLiteEntityProviderServicesConfiguration (dotConnect for SQLite)
If Entity Framework 6.3 provider configuration must be customized, you will need to create a descendant of the DbConfiguration class and set values for SetProviderFactory() and SetProviderServices() in it. Then use this custom class for provider registration. Here is an example for dotConnect for Oracle:
public class OracleConfiguration: DbConfiguration {
public OracleConfiguration() {
SetProviderFactory("Devart.Data.Oracle", Devart.Data.Oracle.OracleProviderFactory.Instance);
SetProviderServices("Devart.Data.Oracle", Devart.Data.Oracle.Entity.OracleEntityProviderServices.Instance);
}
}
Entity Framework Spatials Support for Entity Framework 6.3
Entity Framework Spatials are supported in dotConnect for Oracle, dotConnect for MySQL, dotConnect for PostgreSQL. This support was implemented way back for Entity Framework 5 and Entity Framework 6, working on Full .NET Framework. Most Entity Framework Spatials features, supported for previous Entity Framework versions, are supported for Entity Framework 6.3 and .NET Core 3 too, with the exception of the following.
- Outdated SharpMap and unsigned NetTopologySuite Entity Framework spatial services are not supported, because they don’t have .NET Core-compatible implementations.
- Signed NetTopologySuite is upgraded to the version 15.5.3. However, since Entity Framework features are not required for many Entity Framework users, our NuGet packages don’t reference to the NetTopologySuite package. If you need to use NetTopologySuite, install its NuGet package manually via Package Manager Console: Install-Package NetTopologySuite -Version 1.15.3
- Entity Framework spatial service registration changed. Now it must be performed as early as possible – prior to Entity Framework 6.3 engine initialization. If you have code with Database.SetInitializer preceding Entity Framework spatial service initialization that worked OK with Entity Framework 6.2, it won’t work with Entity Framework 6.3. For example, the following code is correct for Entity Framework 6.2, but won’t work with Entity Framework 6.3:
public class MyContext: DbContext { static MyContext() { Database.SetInitializer<MyContext>(null); var config = OracleEntityProviderConfig.Instance; config.SpatialOptions.SpatialServiceType = SpatialServiceType.NetTopologySuiteSigned; config.SpatialOptions.GeographyDistanceUnit = DistanceMeasurementUnit.Kilometer; config.SpatialOptions.GeographyAreaUnit = AreaMeasurementUnit.SquareKilometer; } }For Entity Framework 6.3, Database.SetInitializer must be called later, like in the following example:
public class MyContext: DbContext { static MyContext() { var config = OracleEntityProviderConfig.Instance; config.SpatialOptions.SpatialServiceType = SpatialServiceType.NetTopologySuiteSigned; config.SpatialOptions.GeographyDistanceUnit = DistanceMeasurementUnit.Kilometer; config.SpatialOptions.GeographyAreaUnit = AreaMeasurementUnit.SquareKilometer; Database.SetInitializer<MyContext>(null); } }
Here you can download sample projects, working with Spatials Data using dotCoonnect for Oracle, PostgreSQL, and MySQL. To test these project, create the necessary database objects using the DatabaseInitializationScript.sql file from the archive subfolder for the corresponding dotConnect provider, for example
\Devart dotConnect for Oracle Demo\DatabaseInitializationScript.sql
Replace the connection string in the project with the actual connection string to the corresponding database. For example, for Oracle, the connection string to replace is in the \Devart dotConnect for Oracle Demo\OracleModel.cs file.
Entity Developer
Of course, Entity Framework 6.3 is now completely supported in our popular and powerful ORM designer – Entity Developer. It is supported for our providers – dotConnect for Oracle, dotConnect for MySQL, dotConnect for PostgreSQL, and dotConnect for SQLite, as well as for Microsoft SqlClient for SQL Server. And now you can select the Devart Entity Model project item when adding an item to a .NET Core project in Microsoft Visual Studio 2019 (Visual Studio 2019 version 16.3 Preview or higher is recommended).
All the Entity Framework 6 templates for C# and VB.NET were updated to support .NET Core 3.0 and loading a connection string from the appsettings.json file. Here is the list of updated templates:
- DbContext
- EntityObject
- POCO Entity
- Self-Tracking Entity
The following properties were added to these templates:
- Json File Base Path – Specifies the base path for file-based providers when a connection string from the appsettings.json file is used. The special reserved value %CurrentDirectory% means that the current working directory of the application is used as the base path.
- Include Environment Variables – Determines whether context configuration will be extended with environment variables when a connection string from the appsettings.json file is used.
Visual Studio 2019 Support
Visual Studio 2019 support is greatly improved in our products. Now installers of all our ADO.NET providers and Entity Developer fully support both integration into the release version of Visual Studio 2019 (ver 16.0/16.1/16.2) and into preview versions (ver 16.3 Preview). You can even integrate our products simultaneously into both the release and preview instances if both are simultaneously installed. Besides our products now work with Optimize rendering for screens with different pixel densities turned on.
Conclusion
We will continue to extend the functionality of our ADO.NET providers for Oracle, MySQL, PostgreSQL, and SQLite and add features for .NET Core 3, based on user feedback. We are going both to extend the legacy features support to ease migration of existing Full .NET Framework projects and implement new features to improve support of Windows, Linux, and Mac OS platforms. Besides we plan to further improve Entity Developer, both as a Visual Studio add-in and as a standalone application, to make development of .NET Core projects more efficient.
