Remove SQLDebugging class

[edwardneal]

This is partially related to the project merge, partially cleanup. It's a breaking change (since I'm proposing the removal of a public API surface) but I don't think the public API surface is ever actually used. I was hoping to make this change after the removal of SQL 2000 support, but the major version bump is a pretty rare opportunity to make this kind of breaking change to the API surface, so I've pulled it forward.

System.Data.SqlClient in the .NET Framework contains a COM-visible SQLDebugging class, and this was ported over to the .NET Framework version of Microsoft.Data.SqlClient. I feel that porting this over was originally problematic, because the COM GUID associated with this class wasn't changed (and thus, someone registering the M.D.S DLL would have overwritten part of the .NET Framework's COM registration)

Looking at the functionality of this class though, we essentially see this act as a relay between the COM ISQLDebug interface and a memory-mapped file ("Global\SqlClientSSDebug" + [process ID]). A version of SQL Server would instantiate the SQLDebugging class via COM, call ISQLDebug.SQLDebug and have these values written out to the memory-mapped file. The client half of this is still present (link): if a SqlConnection is connected to a SQL 2000 or a SQL 7.0 instance and the debugger is attached, it'll read data from the memory-mapped file and execute the sp_sdidebug stored procedure with these values.

This would only work if the SQL 2000 instance was running locally. The OS requirements for SQL 2000 and for .NET Framework 4.6.2 are mutually exclusive, so this part of the API would never be supportable. The API also isn't present in the .NET Core library, so it contributes (slightly) to the project merge.

I've left the client-side part of this (and associated PInvoke cleanups) alone in the hope that it'll make the PR small enough to review and fit into preview3. Is this possible?

[benrr101]

Personally, I'm totally fine with getting rid of old, questionably supported, and rarely used functionality from our APIs. I can't speak for others on the team, tho. I'll add it to the preview 3 milestone so hopefully it'll get reviewed and taken.

That being said, my one question is - what about DCOM? Could the client connect to the SQL 2000 instance via DCOM?

[mdaigle]

LGTM.

[edwardneal]

what about DCOM? Could the client connect to the SQL 2000 instance via DCOM?

The client might technically be able to use DCOM to instantiate the SQLDebugging class on the server, but this wouldn't do anything; the other half of the comms. pathway (a memory-mapped file) relies upon the client and the server both running on the same computer.

[benrr101]

I'd like to get another senior eye on this one real quick @cheenamalhotra @saurabh500 or @David-Engel ?

[David-Engel]

I agree. Go for removal.