Delete SAP SqlAnywhere

[jzabroski]

SapAnywhere is not support on .NET Core by SAP, and the test runner cannot run on .NET Core due to this limitation.

As part of #1178 , I've littered the code with #if NET461 checks. I think Phase 2 should be to move the FluentMigrator.Tests related to SapAnywhere into their own csproj, and only run them on net461. This will likely make it more readable, and easier to delete if we eventually drop support for SapAnywhere.

@eloekset Do you have any insight into whether SAP is still supporting SapAnywhere? My understanding is its mostly used in German and Scandinavian countries, so I thought you might be more an expert than me, as I've never used SAP-anything-anywhere-any-time :)

[eloekset]

I'm afraid it has been dead technology for many years. The previous company I was working for still uses it for the on-prem software, so that's why I added support for SQL Anywhere to FluentMigrator. However, I don't work there any more, and I doubt that I'll ever get into this DB again.

I had contact with some internals of SQL Anywhere, and I mentioned this project and that I had built support for their technology, but they didn't show any interest. I doubt that they will ever support .NET Core, as there was hardly support for the original Entity Framework.

BTW, here's a request to have Microsoft build EfCore drivers for SQL Anywhere, something that they of course won't spend resources on: dotnet/efcore#12153 I suppose it's up to those who still depends on SQL Anywhere to build a community driver.

I support your suggestion to move the tests into a separate csproj.

[eloekset]

If we restructure dependencies, as described in this thread, we'll some time in the future be able to get insight into the usage per provider from the download count at nuget.org.

If some providers stay at 0 downloads for a few version, we could consider dropping the support for those providers.

[eloekset]

This is the latest SQL Anywhere stuff on NuGet. Version 17 of the driver is built for .NET Framework, and it may or may not work for .NET Core 3.X apps. It depends on the internal API calls, whether they are available in .NET Core 3.X. Pre .NET Standard 2.0, it would not even be possible to install a package like this into a .NET Core application.

[jzabroski]

Thanks. I think the big thing is, once you see my PR for #1178 , you'll see how much of a PITA having SqlAnywhere tests live inside the main FluentMigrator.Tests project is, and why it took me hours to resolve all the compile errors when multi-targeting with <TargetFrameworks>net461;netstandard2.0;netstandard2.1</TargetFrameworks>

[jzabroski]

TODO

• Decide on name for common test project. I believe it should be named either FluentMigrator.Testing or FluentMigrator.TestFramework. I believe it should not end in *Tests as that would cause it to be picked up by dotnet test

Progress so far

• Based off Version 3.x should support .NET Core LTS version(s) #1178 progress checked to my fork https://github.com/jzabroski/FluentMigrator
• Updated AssemblyInfo.cs in various projects so that InternalsVisibleTo supports the new test framework project
• Moved into FluentMigrator.Testing
  • IntegrationTestBase
  • IntegrationTestOptions
  • IntegrationTestOptions.DatabaseServerOptions
  • ValidationHelper
  • ValidationUtilities - this is actually in FluentMigrator.Abstractions but only used in the test project?
  • ServiceCollectionExtensions
  • BaseConstraintTests
  • Integration/Processors/BaseColumnTests
  • Integration/Processors/BaseIndexTests
  • Logging/TextWriterLoggerProvider
  • Integration/Processors/BaseSchemaExtensionsTests
  • Integration/Processors/BaseSequenceTests
• Various ambiguous references
  • ServiceCollectionExtensions: CS0104 'ServiceCollectionExtensions' is an ambiguous reference between 'FluentMigrator.Testing.ServiceCollectionExtensions' and 'Autofac.Extensions.DependencyInjection.ServiceCollectionExtensions'
    • I chose our version, which I believe to be correct. Just logging it in case that is the wrong choice, and I suffer the consequences and can't remember a week later why things error out at run-time.
    • D:\source\GitHub\fluentmigrator\test\FluentMigrator.Testing\Unit\IssueTests.cs 38
• Kept out of FluentMigrator.Testing
  • Logic in test classes starting with Obsolete
    • ObsoleteIntegrationTestBase
    • ObsoleteVersionMigrationTestBase
    • ObsoleteMigrationRunnerTests

[jzabroski]

I wrapped this up this morning, but haven't pushed it to my public fork yet. Will update comment above and then stage this change as FluentMigrator 3.3.1, after #1178

[fubar-coder]

@jzabroski SAP has two former Sybase databases: SQL Anywhere (ASA) and Adaptive Server Enterprise (ASE).

It seems that you can use ASA - according to this answhere here - the database from .NET Core over ODBC. There also seems to be an ADO.NET driver for .NET Core on nuget.org.

I also found a .NET Core ADO.NET driver for ASE. Nothing official, but it still seems that there are people out there using the databases, so I guess that it'd be useful to keep the processor/dialect.

[jzabroski]

If we want to support legacy databases via System.Data.Odbc, that is fine, but I think we need some basic sanity checks for what we consider maintainable:

1. Does the database support a docker image or similar for integration tests to be run?
2. Should we upgrade from supporting net461 TFM to net48 so that we can fully utilize net standard2.0 libraries like System.Data.Odbc? I don't think we should support System.Data.Odbc against net461. It's just asking for a lot of support tickets for legacy clients.

My general thought is, we probably:

1. Bump FluentMigrator to v4.0 to allow for semver major breaking changes in API (dropping FluentMigrator.SqlAnywhere is a major API change)
2. Finish merging the existing 4.0 branch with 3.0

Step 2 is the painful part that I have not gotten a chance to complete. I think, rather than trying to do it all at once, we are probably best off doing it incrementally.

[fubar-coder]

@jzabroski I personally don't mind dropping databases that aren't supported in docker, but I'm curious how you specify docker support?

• Is there an official docker image?
• Is there any unofficial docker image?
• Can it run inside a Linux docker container?
  • Is it installable in a Ubuntu image with apt?

Database	Docker Hub link
SQL Server	https://hub.docker.com/_/microsoft-mssql-server
Postgres	https://hub.docker.com/_/postgres
Oracle 12c	https://hub.docker.com/_/oracle-database-enterprise-edition or https://hub.docker.com/r/quillbuilduser/oracle-18-xe or a custom registry with a Dockerfile from https://github.com/fuzziebrain/docker-oracle-xe
IBM DB2	https://hub.docker.com/_/ibm-db2-warehouse-dev or https://hub.docker.com/r/ibmcom/db2
MySQL	https://hub.docker.com/_/mysql
MariaDB	https://hub.docker.com/_/mariadb
SAP Hana	https://hub.docker.com/_/sap-hana-express-edition
SQL Anywhere	https://hub.docker.com/r/jaschweder/sybase or https://hub.docker.com/r/datagrip/sybase
Firebird	https://hub.docker.com/r/jacobalberty/firebird
Microsoft Access (JET Engine)	???

Amazon Redshift might be a challenge...

[jzabroski]

https://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.help.sqlanywhere.12.0.1/dbprogramming/adodotnet-development-secta-3832474.html says:

SQL Anywhere .NET Data Provider features

SQL Anywhere supports the Microsoft .NET Framework versions 2.0, 3.0, 3.5, and 4.0 through three distinct namespaces.

• iAnywhere.Data.SQLAnywhere The ADO.NET object model is an all-purpose data access model. ADO.NET components were designed to factor data access from data manipulation. There are two central components of ADO.NET that do this: the DataSet, and the .NET Framework data provider, which is a set of components including the Connection, Command, DataReader, and DataAdapter objects. SQL Anywhere includes a .NET Entity Framework Data Provider that communicates directly with a SQL Anywhere database server without adding the overhead of OLE DB or ODBC. The SQL Anywhere .NET Data Provider is represented in the .NET namespace as iAnywhere.Data.SQLAnywhere.

The Microsoft .NET Compact Framework is the smart device development framework for Microsoft .NET. The SQL Anywhere .NET Compact Framework Data Provider supports devices running Windows Mobile.

The SQL Anywhere .NET Data Provider namespace is described in this document.

To read more about how to access data stored inside a SQL Anywhere database using the ADO.NET object model, in particular via the Language Integrated Query (LINQ) to Entities methodology, see the SQL Anywhere and the ADO.NET Entity Framework white paper at [external link] www.sybase.com/detail?id=1060541.

• System.Data.Oledb This namespace supports OLE DB data sources. This namespace is an intrinsic part of the Microsoft .NET Framework. You can use System.Data.Oledb together with the SQL Anywhere OLE DB provider, SAOLEDB, to access SQL Anywhere databases.

• System.Data.Odbc This namespace supports ODBC data sources. This namespace is an intrinsic part of the Microsoft .NET Framework. You can use System.Data.Odbc together with the SQL Anywhere ODBC driver to access SQL Anywhere databases.

On Windows Mobile, only the SQL Anywhere .NET Data Provider is supported.

There are some key benefits to using the SQL Anywhere .NET Data Provider:

In the .NET environment, the SQL Anywhere .NET Data Provider provides native access to a SQL Anywhere database. Unlike the other supported providers, it communicates directly with a SQL Anywhere server and does not require bridge technology.

As a result, the SQL Anywhere .NET Data Provider is faster than the OLE DB and ODBC Data Providers. It is the recommended Data Provider for accessing SQL Anywhere databases.

However, it appears iAnywhere is on at least version 17 now, but the .NET Core package maintained by CodeRush only works up to 16. All things considered, we can experiment with using System.Data.Odbc rather than deleting SAP SqlAnywhere altogether. It is probably a much smaller lift to use the generic System.Data.Odbc interface than to actually remove SAP SqlAnywhere support altogether.

[jzabroski]

I did a proof-of-concept of moving to System.Data.Odbc - it seems to work. Will hopefully ship it this week and wrap up 5.0.0 release.

[jzabroski]

Decided to go ahead and just full on delete this lead anchor. Time to cast the sails and cruise away from .NET Framework.

[jzabroski]

@eloekset Pushed. I bypassed PR for this, so let's see if it builds on the build server. If it does not, that is another adventure to go figure out.

[eloekset]

Looks like the GitVersion task has a dependency on .NET Core 3.1 maybe?

[jzabroski]

I am cleaning that up now. UseGitVersion is deprecated in favor of GitTools.

[jzabroski]

Got past that error. Fingers crossed I'm all set: https://dev.azure.com/fluentmigrator/fluentmigrator/_build/results?buildId=705&view=logs&j=12f1170f-54f2-53f3-20dd-22fc7dff55f9&t=53352b99-bc56-513f-dcdf-57009ff4318b

[jzabroski]

Missed a few net462 references. Added a new solution folder called build to prevent that in the future.

[ElDuderinoBerlin]

There is indeed (meanwhile) a NetCore 2.1 driver. Where is the old source code to the SQL Anywhere extension?

Regards

[jzabroski]

.net core 2.1 isn't supported any more. It's been end of life for probably more than a half decade.

What are you trying to accomplish?