Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lib updates and prepare for Microsoft.Data.SqlClient #1313

Merged
merged 38 commits into from Aug 28, 2019
Merged

Conversation

mgravell
Copy link
Member

@mgravell mgravell commented Aug 22, 2019

Intent: make Dapper usable with both System.Data.SqlClient and Microsoft.Data.SqlClient

Details:

  • migrate any System.Data.SqlClient internal details to use runtime magic rather than hard-coded detection (most of this was already done in previous PRs)
  • remove the System.Data.SqlClient dependency
  • change a legacy API from taking a hard IEnumerable<System.Data.SqlDataRecord> to IEnumerable<T> where T : IDataRecord; this makes it a breaking change - although one that is very unlikely to impact many people at all, so:
  • do a semver bump to v2.0
  • change the TFMs slightly; prefer netstandard2.1 to netcoreapp2.1 - the main "point" of the netcoreapp2.1 was to present a "zero dependencies" tree - we get that in netstandard2.1 now
  • update other libs/deps

Note: the removal of System.Data.SqlClient may impact consumers who depended on Dapper to get that ref, but I strongly consider removing it a GoodThing™ for all; folks can add the correct package now. Will need a release note.


Re the semver bump; my view here is:

  • do a "minor" semver bump now to 2.0 for this; the actual code-breaking change will be very low impact in real terms - virtually nobody will notice that, and recompiling fixes it
  • the removal of System.Data.SqlClient is a more noticeable v2.0 change; release notes
  • the API/strong-name changes should be in a separate 3.0 bump
  • I feel no qualms about doing multiple majors

@mgravell
Copy link
Member Author

Suggest look at dotnet/SqlClient#30 (comment)

@mgravell mgravell changed the title Lib updates and prepare for Microsoft.Data.SqlClient WIP: Lib updates and prepare for Microsoft.Data.SqlClient Aug 22, 2019
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be able to delete this app.config and it generate as the <name>.config file in the output directory

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nope, doesn't generate the binding for Microsoft.SqlServer.Types if you do that; is needed

@@ -20,6 +20,6 @@
<Reference Include="Microsoft.CSharp" />
</ItemGroup>
<ItemGroup Condition="'$(TargetFramework)' == 'netstandard1.3'">
<PackageReference Include="Microsoft.CSharp" Version="4.3.0" />
<PackageReference Include="Microsoft.CSharp" Version="4.5.0" />
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's drop netstandard1.3 from all builds

</ItemGroup>
<ItemGroup Condition="'$(Platform)'=='x86'">
<Content Include="$(USERPROFILE)\.nuget\packages\microsoft.sqlserver.types\14.0.1016.290\nativeBinaries\x86\*.dll"
Condition="'$(TargetFramework)' == 'net46' OR '$(TargetFramework)' == 'net472'">
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's move these conditions to the ItemGroup (same above)

<ItemGroup Condition="'$(TargetFramework)' == 'netcoreapp2.0'">
<PackageReference Include="Microsoft.Data.Sqlite" Version="2.0.0" />
<PackageReference Include="Microsoft.Data.Sqlite" Version="2.2.6" />
</ItemGroup>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can drop this block with netcoreapp2.0 build drop

}
finally
{
connection.Execute("DROP TYPE int_list_type");
try { connection.Execute("DROP TYPE int_list_type"); } catch { }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's double check if we need these with the collections defined now

@@ -686,6 +741,8 @@ public void DBGeography_SO24405645_SO24402424()
[Fact]
public void SqlGeography_SO25538154()
{
if (IsMsDataClient) return; // not supported
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dapper/Dapper.csproj Outdated Show resolved Hide resolved
@mgravell mgravell merged commit 8152f2c into master Aug 28, 2019
@NickCraver NickCraver changed the title WIP: Lib updates and prepare for Microsoft.Data.SqlClient Lib updates and prepare for Microsoft.Data.SqlClient Aug 28, 2019
rhubley pushed a commit to rhubley/Dapper that referenced this pull request Jan 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants