-
Notifications
You must be signed in to change notification settings - Fork 286
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
Synchronize ref definitions #180
Conversation
I started looking at the changes and there are quite a few additions to the netcore ref file beyond the designer attributes.
|
removed from SqlConnectionStringBuilder.ConnectionReset, ContextConnection, NetworkLibrary, TransparentNetworkIPResolution. removed SqlCommand.NotificationAutoEnlist. |
I write a program which dumps the definitions from a binary and then did some manual comparisons. interesting results overall. net462-ref.txt |
The comparisons are definitely interesting. I'm having to do a lot of research for this PR. Learning new things is not bad. Some questions in my mind are:
We don't have any tests around the ref definition, so verifying this PR is all manual. It might be easier if this were split into different PRs where we can easily accept a round of reformatting/white space changes, a round of only sorting changes (no lines added or changed), and then a round of actual changes where we can ask questions about specific changes. Like why has |
From my understanding they should never. They can differ with varying consequences, least damaging is the metadata. The only purpose of the ref assemblies is to be bound against by compilers when the exact TFM+RID version has not or can not be determined. If something exists in ref but not impl then an attempt to use it will cause a runtime failure. If something exists in impl but not ref then it may or may not be visible to the compiler which could cause editor/intellisense visibility strangeness or compiler errors complaining about missing types. The attributes I took over are all the ones that didn't need any additional references. The Security attributes are irrelevant on netcore, security is stubbed. The rest were componentmodel designer metadata which influences the propertygrid and other visual studio designer experiences, so not needed but having them present will make things feel more natural to people who use visual designers. HostProtectionAttribute was the only one that I didn't attempt to sync, that doesn't exist and won't on netcore because the reliability infrastructure it's part of is not in that runtime.
Any type which has a language keyword can use that language keyword. Anything which does not should use a fully qualified name. My assumption for this is that it prevents there being any possibly namespace mistakes by virtue of there being no using directives at all, everything must be explicit about the exact type. The ref assemblies can be tool generated in corefx which is why everything is strictly in alphanumeric order.
if an attempt is made to use the ref assembly as an impl is made it should fail as soon as possible. throwing null is the pattern used throughout the other ref assemblies for this so if it was missing I added it.
That's what I assume. Since Close is inherited from DbDataReader it will have been present in the intellisense from the base type so even if you looked for it you'd find it and the callvirt would mean you called the right one. Not a damaging oversight. It does make it clear that the existing ref in corefx wasn't tool generated. I can rework from the beginning but I'm not sure it'll be less confusing to do so. The process logically involves diffing the files and making repeated rounds of modifications to limit the diff output. interim points in the process have no relative value, |
public event Microsoft.Data.SqlClient.SqlInfoMessageEventHandler InfoMessage { add { } remove { } } | ||
protected override System.Data.Common.DbTransaction BeginDbTransaction(System.Data.IsolationLevel isolationLevel) { throw null; } | ||
public new Microsoft.Data.SqlClient.SqlTransaction BeginTransaction() { throw null; } | ||
public new Microsoft.Data.SqlClient.SqlTransaction BeginTransaction(System.Data.IsolationLevel iso) { throw null; } | ||
public Microsoft.Data.SqlClient.SqlTransaction BeginTransaction(System.Data.IsolationLevel iso, string transactionName) { throw null; } | ||
public Microsoft.Data.SqlClient.SqlTransaction BeginTransaction(string transactionName) { throw null; } | ||
public override void ChangeDatabase(string database) { } | ||
public static void ChangePassword(string connectionString, Microsoft.Data.SqlClient.SqlCredential credential, System.Security.SecureString newSecurePassword) { } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How come throw null;
was removed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure. There were a bunch of other methods near it that didn't throw either so I've added it to a few. I'm going to see if can track down the exact rules for this since my knowledge is based on seeing ref edits and review feedback on my own.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am a bit confused, too, why some include it and some don't. So I'm curious what you find out. I don't feel like it's a blocker, though, given my understand of ref.
src/Microsoft.Data.SqlClient/netcore/ref/Microsoft.Data.SqlClient.cs
Outdated
Show resolved
Hide resolved
src/Microsoft.Data.SqlClient/netcore/ref/Microsoft.Data.SqlClient.cs
Outdated
Show resolved
Hide resolved
src/Microsoft.Data.SqlClient/netcore/ref/Microsoft.Data.SqlClient.cs
Outdated
Show resolved
Hide resolved
src/Microsoft.Data.SqlClient/netcore/ref/Microsoft.Data.SqlClient.cs
Outdated
Show resolved
Hide resolved
|
I don't see an impl in netfx. I think |
@Wraith2 I think this is good to merge as-is. If you want to add the |
If you're happy with the current state I'd say merge it. I can come back to null throwing and the SqlFacetAttribute later in a dedicated PR if they need changes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cheenamalhotra This LGTM. Tagging you for a second set of eyes.
src/Microsoft.Data.SqlClient/netcore/ref/Microsoft.Data.SqlClient.cs
Outdated
Show resolved
Hide resolved
NuGet package available for this PR here: 1.1.0-build.19255.1-53d2128 |
This PR syncs the definitions of netcore netstandard and netfx ref projects where possible. This is mainly by reordering the types into but some attributes have been added to netcore where they were present in netfx since this isn't an interface change and enhances mainly designer experiences. It's now possible to diff the ref definitions and get a pretty clear picture what the differences in public surface are between the different versions.