Support .NET Core, as well as .NET Framework

[tsahi]

Is your feature request related to a problem? Please describe.
Enterprise Library as a whole, and DAAB in particular, were last released in 2013, long before .NET Core was released. As .NET Core is the future of .NET, we should support it. At the same time, .NET Framework is still widely used, and we want any new features to be available to .NET Framework as well.

Describe the solution you'd like
We should refactor the code to a Shared Project, and consume it from a .NET Core and a .NET Framework projects, with the necessary technique (e.g. DI) to accommodate for the differences.

Describe alternatives you've considered
There is a port of EntLib to .NET Core https://github.com/EnterpriseLibrary/data-access-application-block, but it didn't add any new functionality. We may work with them though.

[tsahi]

Or compile as .NET Standard 1.4, which is the latest that works with .NET Framework 4.6.1 with no issues. .NET 4.6.1 is still widely used, as it's the standard version coming with Windows Server 2016.

we should experiment with a demo project to see how well .NET Framework 4.6.1 and .NET Core consume .NET Standard libraries.

We should see if we are lacking API we need in .NET Standard 1.4.

[tsahi]

interesting read: https://weblog.west-wind.com/posts/2017/Jun/22/MultiTargeting-and-Porting-a-NET-Library-to-NET-Core-20

[tsahi]

Need to see if Microsoft.Data.SqlClient (see #7 ) works with .NET Standard 1.4.

[tsahi]

check if nullable types work with .NET Standard 1.4: https://devblogs.microsoft.com/dotnet/embracing-nullable-reference-types/?utm_source=vs_developer_news&utm_medium=referral

[tsahi]

We also need to fork MicrosoftArchive/enterprise-library-common-infrastructure, and convert to .NET Standard, because this project depends on it. It can be useful if we work on other application blocks too.

[tsahi]

correction: we should support .NET Framework 4.6.2, and not 4.6.1. this doesn't change the .NET Standard target.
while working on this, I found out there are many APIs missing from .NET Standard 1.4. In particular, the System.Configuration namespace and TypeConverter.
System.Configuration exists as a nuget for .NET Standard 2.0, but this means only supporting .NET Framework 4.7.2+. And we should ask ourselves what does it mean when working in .NET Core environment, which has a completely new configuration model. It can work with the old app/web.config files through nuget packages, but this is, I believe, for easier conversion of .NET Framework apps to .NET Core. A new .NET Core app shouldn't use that. which means we should provide a different configuration model when running under .NET Framework and under .NET Standard.

[tsahi]

My current preference is to use Shared Project. But for that, first I need to fix the unit tests, because too many of them fail.

[tsahi]

most unit tests for the Oracle support in the Data solution don't work, mostly due to referencing non-existent database objects. these will be fixed one at a time, as much as possible.
initially, tests failed because of x86-x64 incompatibility, but this was fixed by forcing tests to run in x64 at commit fc55abd

[tsahi]

At this point, the only tests that don't pass are Oracle tests. These fall into two categories:

1. Parameter discovery failure. The OracleCommandBuilder.DeriveParameters() in System.Data.OracleClient fails to discver parameters for stored procedures, and as a result, assigning values to parameters fails, and the call to the procedure fails for number of parameters mismatch.
2. Unicode. There are several tests which compare expected values with actual values, where the values contain diacritics in French an Spanish. These tests fail, because the data returned from the database has bad encoding. I tried to solve this several ways, with no success.

it's quite possible that replacing the System.Data.OracleClient implementation with ODP.NET, will solve these issues. This is one of the next things I will check.