You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Today there is one big package that supports SQL Server, Oracle, and SqlCE. There is no reason people using SQL Server will take a dependency on packages supporting Oracle, and vice-versa.
Describe the solution you'd like
We should split the package to several packages, so that:
One base package will carry the base functionality, e.g. the abstract Database class, the caching, etc.
A SQL Server package will depend on the base package, but will also depend on Microsoft.Data.SqlClient.
An Oracle package will depend on the base package, but will also depend on Oracle.ManagedDataAccess[.Core]
A SqlCE package will depend on the base package. This won't bring new dependencies.
A Generic (very small) package will depend on the base package, exposing the GenericDatabase for use with OldDb provider.
Additional context
of course, once we support .NET Core, the dependencies will be on the .NET Core or .NET Framework versions of each database-specific package.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Today there is one big package that supports SQL Server, Oracle, and SqlCE. There is no reason people using SQL Server will take a dependency on packages supporting Oracle, and vice-versa.
Describe the solution you'd like
We should split the package to several packages, so that:
Additional context
of course, once we support .NET Core, the dependencies will be on the .NET Core or .NET Framework versions of each database-specific package.
The text was updated successfully, but these errors were encountered: