.NET core support

[1TheMuffinMan]

It appears that the Nuget package doesn't have .NET core supported even when using the standard framework.

I'd like to contribute to making this happen if possible, but is this simply a matter of adding the support in the nuspec, or is there possibly code changes needed as well?

[tmenier]

I think it's a great idea and I'd gladly accept a PR for it. I'm afraid I don't know exactly what would be involved though.

[1TheMuffinMan]

Awesome. I ran the library through a tool that checks if any dependencies are not supported. It looks pretty good so far. The only one is MySql.Data is in prelease so we should probably wait until it's ready.

Check it out here https://icanhasdot.net/result?github=tmenier~2FAsyncPoco

[tmenier]

Sweet! So it should just be a nuspec change? Do you want to take a crack at it and submit a PR? I could deploy the new package as a prerelease and let others test it. And like you say, maybe we hold off on the the full release until MySql.Data is ready.

[bgrainger]

The MySql.Data dependency can be fixed by switching to MySqlConnector (which has supported .NET core since its first release): #36.

[tmenier]

@1TheMuffinMan Any progress on this?

@bgrainger The NuGet package doesn't have a dependency on any driver, so that's not really relevant.

[kevinsbennett]

how about just supporting netstandard 2.0 instead?

[tmenier]

@1TheMuffinMan @kevinsbennett I'm actively working on .NET Core support, via .NET Standard 1.3 and 2.0. This will likely form the basis of AsyncPoco 2.0. I would also like to trim a few things for 2.0. Out of curiosity, do either of you use the single drop-in file (AsyncPoco.cs) OR use the T4 templates? Or do you just pull in the NuGet package and go? I am strongly considering dropping both of those.

[1TheMuffinMan]

I used AsyncPoco pretty extensively this past year, and just pulled in the NuGet package. I think I used the Core without the T4 templates.

[kevinsbennett]

We had to modify a couple minor things so we brought in the source code. However, we can take a closer look to what we modified and whether those make sense to do a PR for AsyncPoco 2.0. We would NOT be using the T4 template nor the single drop in file. Preferred would be NuGet.

[tmenier]

Perfect, thanks for the feedback.

[moodmosaic]

As @kevinsbennett wrote, we had to modify a couple of (minor, for us at least) things in the source code:

• Workaround the lack of dynamic DbProviderFactory loading in .NET Standard. See https://github.com/dotnet/corefx/issues/4571 on DbProviderFactories (backstory on why this hasn't been implemented)

  -    // If a provider name was supplied, get the DbProviderFactory for it
  -    if (_providerName != null)
  -        _factory = DbProviderFactories.GetFactory(_providerName);
  +    // If a provider name was supplied, get the DbProviderFactory for it
  +    if (_providerName != null)
  +        _factory = SqlClientFactory.Instance;

• Use ThrottlingCondition from Azure/elastic-db-tools
• Remove T4 templates (since we're not using them)
• Depend on the following NuGet Packages:
  • EnterpriseLibrary.TransientFaultHandling.Core
  • System.Data.SqlClient
  • System.Reflection.Emit.ILGeneration
  • System.Reflection.Emit.Lightweight

• End up having a minimal csproj as shown below

  <Project Sdk="Microsoft.NET.Sdk">
  
  <PropertyGroup>
    <TargetFramework>netstandard20</TargetFramework>
  </PropertyGroup>
  
  <ItemGroup>
    <PackageReference Include="EnterpriseLibrary.TransientFaultHandling.Core" Version="1.2.0" />
    <PackageReference Include="System.Data.SqlClient" Version="4.4.2" />
    <PackageReference Include="System.Reflection.Emit.ILGeneration" Version="4.3.0" />
    <PackageReference Include="System.Reflection.Emit.Lightweight" Version="4.3.0" />
  </ItemGroup>
  </Project>

[tmenier]

@moodmosaic Thanks for the insights. I've already worked through most of these but I'll cross-check my stuff with your findings before I push. For DbProviderFactories I ended up doing sort of a shim based on the source that's in 2.1.

At this point I'm targeting .NET Framework 4.5, .NET Standard 1.3, and .NET Standard 2.0. That should give very broad cross-platform support.

[tmenier]

Well, it didn't take long to discover that simply dropping in a DbProviderFactories shim isn't enough to get the dynamic factory loading to work. Going to have to resort to something like this:

https://weblog.west-wind.com/posts/2017/Nov/27/Working-around-the-lack-of-dynamic-DbProviderFactory-loading-in-NET-Core

[tmenier]

...And back to the drawing board. Trying to compensate for .NET Core's lack of support for resolving a DbProviderFactory by provider name is an utter mess, and I can't find examples of other ORMs that even attempt it. NPoco simply doesn't support it on .NET Core. (To create a Database, you need to supply an existing DbConnection or a DbProviderFactory.) Dapper had the foresight to design their entire API around extension methods off IDbConnection, so they don't even need to deal with it. PetaPoco doesn't support .NET Core.

So I'm basically going to follow suit and not support creating a Database by provider name, nor by connection string name (which uses provider name indirectly), on .NET Core. You'll have tell it what db platform you're on in a more direct way. I don't think most people even know what a DbProviderFactory is, but most know what a DbConnection is, and that's really all it needs to know, so I'm hoping these new ways to create a Database are as painless as possible:

Database.Create<SqlConnection>(connStr);
Database.Create<OracleConnection>(connStr);
Database.Create<MySqlConnection>(connStr);
// etc.

Those all assume (and enforce) that the supplied type has a parameterless constructor, which every implementation I've seen does, but just in case you want to provide any custom construction, you can also use this overload:

Database.Create(() => new SomeDbConnection(...));

Support for new Database(existingConnection) will still be there (all platforms), as will most or all of the other constructors (full framework only) from 1.x.

This is all very much a work in progress so let me know if you have any thoughts/concerns on this direction.

[1TheMuffinMan]

The example you show looks pretty clean/straight forward to me.

For this DbProviderFactory is the implementation too complex to view the source, and implement it in .net core?

[tmenier]

Yes, that's what I tried to explain above. It's a nasty rabbit hole that's not worth going down for such little gain. Rick Strahl's article that I linked to above explains it in more detail.

[tmenier]

The first prerelease is now available!

https://www.nuget.org/packages/AsyncPoco/2.0.0-pre1

.NET Core 1.0 and 2.0 are supported. Anyone able to help out and do some testing?

[tmenier]

FYI, I created a 2.0 upgrade guide in the wiki, although it's nothing I haven't already covered here.

[csurfleet]

I've just brought in the 2.0 prerelease version, its only being used for test-data setup in a unit test project so a good place to try it out. I'll try and remember to update back here, but remind me in a couple of weeks if I haven't ;)

[tmenier]

Prerelease 2 is now available on NuGet if anyone wants to check it for regression bugs. I'm not too worried, it was mostly just some cleanup and minor refactoring (and major refactoring of the test project). If I don't hear anything in the next few days I'll strip the -pre and go with this as the stable release.

Thanks for your help getting to this big milestone!

[tmenier]

Stable 2.0 release is now available!