CoreFX implications

[martinjw]

CoreFX won't have DataTables, but they are replacing DbConnection.GetSchema which is the core of dbSchemaReader.

CoreFX issue: https://github.com/dotnet/corefx/issues/3423
and https://github.com/dotnet/corefx/issues/5024

The current proposal looks like our data schema model, which is promising. This library could then depend on the CoreFx model and schema reading (a more solid base than the existing GetSchema datatables).

We'll see what the final version looks like before deciding whether we wrap it with our model, or extend their model. Whichever, this library could potentially be a good bridge to support both older full framework and CoreFx.

Not looking forward to the conditional compilation directives though.

[martinjw]

Started work on v2.0 based on RC2. Very early days, but some design notes...

• Model is simplified, removing circular references (makes some things a little harder, but xmlserialization is now possible)
• Completely custom schema reading must be built for each client (instead of relying on provider's defaults). More work, but the sql can be more efficient, and async may be possible (for .net4.5+).
• Some providers may be problematic (Oracle's BindByName, discovered by reflection).
• The higher level functionality - CodeGen, SqlGen, Compare - uses the same model so should not have much change. I hope.
• Using project.json with frameworks "net35", "net40", "net45" and "netstandard1.5".
• VS2008 solution/projects gone. Only VS2015 (with Core Preview1+). The Core stuff can't be used in old Visual Studios
• Test project is now XUnit (no more MsTest/NUnit dual testing)
• Viewer will probably remain as a net35/net45 Windows Forms, but VS tooling doesn't seem to support mixed solutions yet. This may have to wait until Visual Studio 15, I guess next year.

[martinjw]

• Test projects not converted, and VS tooling has been too unstable. Will wait until VS 15 (2017?), but for now there are 2 solutions, a VS 2015/.net 4.5 legacy solution, and a Core tooling RC2 solution with scraper and a minimal test project.

https://github.com/martinjw/dbschemareader/releases/tag/2.0.0

Merge into master this weekend.

[martinjw]

Documentation on netstandard: https://dbschemareader.codeplex.com/wikipage?title=NetStandard

[martinjw]

Merged, pushed to Codeplex mirror and Nuget.

To do:

• CodeGen for EF Core
• XmlSerialization is possible, but some circular references are avoided with XmlIgnore. Provide a helper method to hook up the model after deserialization.
• Consider DB2 support in Core. It's in EF Core's roadmap (even if IBM doesn't seem to be doing anything with .net Core yet). Not iSeries...

[martinjw]

Visual Studio 2017 is released March 7 2017. Next step is to upgrade the DatabaseSchemaReaderCore.sln/projects to VS2017 csproj format. Existing non-core project will probably be named "DatabaseSchemaReader2015.sln".

[martinjw]

For my reference...

Trial conversion with Visual Studio 2017RC works.

"dotnet build" command line fails for .net 3.5 because of this issue:
dotnet/msbuild#1333

For command line, the full msbuild works (only the 2017 version, obviously; this must be what VS uses)
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\MsBuild.exe" DatabaseSchemaReader.csproj /p:TargetFramework=net35

Will redo when I have the VS2017 RTM.

[martinjw]

VS2017/Core+multi-targeting version added (solution DatabaseSchemaReader.sln)
Separate VS2015/non-Core version added (solution DatabaseSchemaReader2015.sln)

Appveyor now has VS2017 image, but no database services, so build is still failing. Just waiting on appveyor now...

[vhatsura]

Do you have any updates?

[martinjw]

Core/netstandard 1.5 is working fine
Creating the reader is a little different to full framework, and it excludes some features. https://github.com/martinjw/dbschemareader/wiki/netcore

Core/netstandard 2.0 just added (yesterday...). Shortly I will enable some of the excluded features (reading data, stored procedures).

The invocation will remain different between core and full framework. DbProviderFactories doesn't exist in netstandard 2 due to the completely different configuration model (although there is a stub DbProviderFactory).

[vhatsura]

Thanks, sounds good.

[martinjw]

Support for both netstandard 1.5 and extra APIs for netstandard 2.0