Why is there no System.Data in netstandard20? about standard HOT 12 CLOSED

@FransBouma, thanks for filing this!

To be very clear: .NET Core already does and will continue to support System.Data. We currently have a dev prototyping adding virtually all of the generic ADO.NET namespaces, i.e. System.Data and System.Data.Common, including DataSet and DataTable. And not just any dev -- it's @stephentoub 😄

We currently don't have plans to include the precursor of EF, Linq-to-SQL, spatial support, OleDb, ODBC, or the (deprecated) Oracle client.

Now to the question whether we should add System.Data to .NET Standard. Adding it to the standard means that all .NET platforms have to support ADO.NET. I can see this being the case for the abstractions and the general ADO.NET facilities (including DataSet). We probably would never do this for concrete providers, as their applicability varies (e.g. it's a highly unlikely scenario to use the SQL Server client from an iOS device, but it would make sense to use a provider that can store data on the device, such as SQLite).

The alternative to adding System.Data to the standard would be to provide it as a set of NuGet packages that target .NET Standard. For the most part, being part of .NET Standard vs. being available for .NET Standard is virtually the same thing:

• Class libraries targeting .NET Standard can use it.
• All applications across all .NET platforms can use it.

The only real difference is:

• You need to add references to these components

We haven't made a final decision yet, but my guess is that we're likely adding the provider-independent parts of ADO.NET to .NET Standard.

from standard.

ah I now realize what my critical thinking error is. Bear with me, I hope to explain it so others who read this and make the same mistake aren't as confused as I was:

I was thinking that I would reference .NET full as that implements netstandard20, and that would work if I then target netstandard20. (like targeting .net 4.0 or .net 4.5 means you reference the same mscorlib.dll) But that's of course not correct: if you target netstandard20, you reference the netstandard20 assembly and not the .net full mscorlib. So there's no way to call a method not in the standard as that would be the same as calling a method that's only in .net 4.5 if you referencing .net 2.0's mscorlib.

So when I realized that, and re-reading you guy's comments, the broken switch to switch on the lightbulb in my head suddenly came to life and all was clear. Hopefully that clears things up for others who might be confused as well.

This then also helps with my initial question, and my concerns: indeed, if an assembly isn't in the standard but depends on the standard it's just the same as today indeed when you reference .net 4.5 and reference an assembly from nuget.

All clear! 😎

from standard.

We currently don't have plans to port the OleDb and Odbc providers to other .NET platforms, such as .NET Core. Also, they don't exist in Xamarin; Mono has both of them but I'm not sure what their status is. I'll take a look.

from standard.

No there's another difference: they don't version with netstandard20. This is actually a problem because you can't simply 'target' netstandard20, you have to target netstandard20 + whatever version the system.data assemblies have.

I'm not sure I follow. The way this would this would work is the same how it will work for other components, such as System.Collections.Immutable. Let's say I create a NuGet package that uses immutable collections. These are the assets and how they relate:

• My package (Immos.Cool.Thingie) depends on both, .NET Standard as well as SCI
• System.Collections.Immutable in turn depends on .NET Standard
• All lib folders target .NET Standard
• The versions of the packages are largely irrelevant; the compat decision is a function of the lib folder name and version, as it has always been in NuGet.

In that sense, it doesn't matter whether the functionality is part of .NET Standard or is provided for .NET Standard -- so long all the target frameworks agree, you can run in exactly the same contexts. The same is true for any 3rd party library, by the way, such as JSON.NET.

There's another, more important problem: For porting code, especially large libraries like the ones I maintain, it's crucial I can target a standard platform, i.e. NET4.5, netstandard20. This will help simplify porting efforts.

Agreed! That's why it's so important to us that we make the contents of .NET Standard useful by itself, rather than building the most minimal API set.

Btw, some time ago (2 years I think) I forked Linq to SQL (https://github.com/FransBouma/LinqToSQL2) from reference source and refactored it a lot. I didn't have time to finish it but if time permits I will port to to netstandard20 as that would be easier then :) Cheers!

That's cool! Once we ship a preview of .NET Standard 2.0, I'd love to hear how this is working for you.

from standard.

Now to the question whether we should add System.Data to .NET Standard. Adding it to the standard means that all .NET platforms have to support ADO.NET. I can see this being the case for the abstractions and the general ADO.NET facilities (including DataSet).

That would be enough I think: the interfaces + System.Data.Common so generic ADO.NET code (like most ORMs/microORMs) can be ported easily by simply targeting .NETStandard20

The only real difference is: You need to add references to these components

No there's another difference: they don't version with netstandard20. This is actually a problem because you can't simply 'target' netstandard20, you have to target netstandard20 + whatever version the system.data assemblies have. If they version differently (and as they're not part of the standard, that's highly likely) it will break any code using them.

There's another, more important problem: For porting code, especially large libraries like the ones I maintain, it's crucial I can target a standard platform, i.e. NET4.5, netstandard20. This will help simplify porting efforts. If some parts aren't in the standard, it already makes things difficult, because those parts are a liability to be able to run on netstandard20 frameworks. Any promise that system.data will be versioned with the standard is nice, but in the end not worth anything: you can't compile against a promise. :)

We haven't made a final decision yet, but my guess is that we're likely adding the provider-independent parts of ADO.NET to .NET Standard.

That would be great! Any provider's specific code is currently also already special code, any generic code targeting the interfaces/base classes in system.data(.common), will then be portable to netstandard20 reliably, so that's a great win for the future foundation of the frameworks building on top of .net.

Btw, some time ago (2 years I think) I forked Linq to SQL (https://github.com/FransBouma/LinqToSQL2) from reference source and refactored it a lot. I didn't have time to finish it but if time permits I will port to to netstandard20 as that would be easier then :) Cheers!

from standard.

I don't see System.Data making a comeback. Much of it was excluded in .NET Core, and according to the documentation for netstandard, it was entirely excluded this go around. This is despite apisof.net showing almost 16% usage.

Even though Mono along with Xamarin.IOS and Xamarin.Android all had some amount of support for System.Data and the Odbc, OleDb, and Sql clients.

from standard.

I know it was excluded but that's not telling me why. There's not a platform out there which doesn't have a data story, every app needs data, even if it reads from sqlite. If Xamarin.* are the deciding factors, IMHO it's still a lowest common demeanor system and that doesn't bode well.

Immo told me there will be a System.Data built on top of netstandard but the versioning of that is unclear: if it versions differently from netstandard, apps compiled against netstandard + the aforementioned system.data library will break and have a problematic time.

Frankly I have no idea why there isn't at least System.Data.Common in netstandard20. Even Compact Framework had it, and due to that it was easier to port a data framework to that framework than it is to .net core and without system.data(.common) in netstandard20 this won't change.

from standard.

Ok, makes sense, but I'm a bit confused I think about 'what does targeting netstandard20' really mean. If I write lib L, which targets netstandard20 and uses system.data, what happens if I call a method which isn't in netstandard20? Will I get an error?

The point I struggle with is: if the method isn't in netstandard20 but in a class that is in a library which supports netstandard, what happens if I call that method in my code which is in a lib that targets netstandard20? If I get an error, because the code isn't netstandard20 'compliant', isn't it then impossible to write netstandard20 code with libraries that aren't in the standard? If it doesn't give an error, how will that method then turn out to be called at runtime on a platform where the method isn't present (as it's not in the standard)? And... what does this mean for my code if I say 'it's compiled against netstandard20', but it calls a method which isn't in the standard?

from standard.

I'm a bit confused I think about 'what does targeting netstandard20' really mean.

Targeting .NET Standard is very similar to targeting a concrete platform, say, .NET Framework. The only difference between targeting .NET Standard and .NET Framework is that the you reference the .NET platform itself through NuGet as well. In case of .NET Framework, the platform is located by pure build magic which resolves it against C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v<Version>. In case of .NET Standard, it simply comes from the netstandard NuGet package (name pending).

We're currently defining .NET Standard 2.0. In general, we can decide to provide functionality via the netstandard package or via another package that simply depends on it. From a standard's perspective, it means the functionality isn't mandatory -- only APIs that are part of the netstandard package have to be implemented by all .NET platforms. However, if that other package can be implemented in such a way it only depends on .NET Standard (i.e. no native dependencies, no OS dependencies, no .NET platform specific bits etc) then it's de facto available everywhere as well.

Does that make sense?

from standard.

That still doesn't answer my question I think, namely if I call a method that's not in the standard, will I get an error or does it compile correctly? If as you say it's equal to targeting a given platform, code that calls a method that's not available on that platform (e.g. a given overload) will cause a compile error.

What I'm after is whether I can look forward to having a single code base which targets netstandard20 and after compilation it results in a single assembly or that I have to have multiple code bases, one for e.g. NET 4.6, one for .NET core etc. I don't mind having multiple code bases (same code files, different compilation directives etc.) , but it would be nice if it would be just one.

from standard.

What exactly do you mean by "call a method that's not in netstandard? Say you reference the netstandard platform and System.Data wasn't available in intellisense, you would add the System.Data package and then things will work. That System.Data package can target netstandard as @terrajobst said and things will just work.

Yes you can have a single code base as the APIs will be the same by you have to add more packages to get things that aren't referenced by default like System.Data.

from standard.

This sounds good. Do wonder though if there will be support for ODBC at least to get access to generic providers. ODBC is cross plat so this would actually be a good fit for generic data access. If not natively in the standard then hopefully as a separate library?

from standard.