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.