[Wasm] Enable System.Data.Common tests

[steveisok]

Disable the tests that require SQL Server.

[ghost]

Tagging subscribers to this area: @roji, @ajcvickers
Notify danmosemsft if you want to be subscribed.

[MaximLipnin]

#38963

[roji]

@steveisok is it possible to get a bit of context on why the DbProviderFactories and DataView APIs aren't supported on WASM?

[steveisok]

Not sure the official reason. I was carrying it over from mono/mono.

I suspect the reason for DbProviderFactories may be to really safeguard you from running into a wall w/ SqlClient ;-). That's just not going to work through a browser.

[ajcvickers]

@steveisok On the other hand, the SQLite ADO.NET provider already works on WASM, so any decisions here should not be based on whether or not the SQL Server ADO.NET provider will work. ADO.NET in general should work.

[steveisok]

@lewing Do you have any insight on this?

[lewing]

@ajcvickers we don't want to break things needlessly but we want to make sure the use experience is good, can you help with guidance here?

[roji]

In principle, I don't see a reason not to allow using DbProviderFactories, DataView or anything else that's under System.Data - these APIs seem to be implemented in pure .NET (no native dependencies or similar), and as @ajcvickers they can be used just like on .NET Core to work with Sqlite. It's possible that mono simply has/had a somewhat outdated implementation of DbProviderFactories.

There are also various other database providers out there, which may or may not work with WASM. I don't think we need to do anything in System.Data itself to block anything - whether a provider works or not should be their issue.

[lewing]

Ok I think we'll roll back the PNSE and just disable the tests that require SQL Server.

[akoeplinger]

Looks good in general, just one comment.