The .NET support black hole

Today I ran into a bit of an issue. A work-item for LLBLGen Pro v5.1 is to support all the new features of SQL Server 2016. One of the features of SQL Server 2016 is ‘Always Encrypted’. You can enable this feature through the connection string, and after that all data-access is encrypted, no further coding needed. As this is a connection string setting, it’s enabled in every ORM out there out of the box, also in ours. That’s of course not the problem. The problem is adding more control over this feature to the developer writing code which targets SQL Server 2016.

Starting in .NET 4.6, the SqlClient API offers a way to specify when and when not to encrypt using SQL Server 2016. This is done through a setting in SqlCommand’s constructor: you can specify a SqlCommandColumnEncryptionSetting value which gives you control over when to encrypt and when not to encrypt, which could greatly enhance performance if you just partly encrypt your catalog.

There’s something odd though: Although SqlCommand has a property for this, ColumnEncryptionSetting, it’s read-only. Its backing variable is set through the constructor. Now, why is this a problem, you ask? Well, unless your code is creating SqlCommand instances directly, you can’t set the setting for a given SqlCommand instance: if you use DbProviderFactory, and most ORMs do, or if you use CreateCommand() on the connection object, you can’t set the setting. You can only set it if you directly use the constructor.

Any database-generic code out there uses either DbProviderFactory or the CreateCommand() method on the connection object, and thus can’t use this feature.

The problem

Looking at this, somewhat terribly designed SqlCommand API, I wondered: “Ok, there’s a serious problem with this API, where can I give feedback so they can fix it?”. I couldn’t answer that. With a product you purchase from a vendor, you can do to that vendor’s support channel, ask them what they think should be done to get this resolved and you eventually reach a conclusion, but here, I have literally no idea.

With .NET Core, most development regarding .NET within Microsoft is focused on that, and a lot of airtime is given to that on GitHub, blogposts etc. But .NET full, e.g. v4.6.2, where do you go with an issue like this? Connect? Mail someone within Microsoft, hoping they’ll route it to some person who won’t delete it right away and look at it? About Connect I’ll be short: no way in hell am I going to spent another second of my time on this planet in that crappy system. Not only does the .NET team not reply to any issues there, I still have some open issues there which are years old and no-one bothers to answer them. It’s like writing the problem into some text file and never look at it again, same result.

About emailing someone within Microsoft: that might work, but it also might not. I happen to know some people within Microsoft and I’m sure they’ll at least read the email, but it’s a silly way to give feedback: here we have a mega-corporation which makes billions of dollars each month, says to be a developer focused company and you have to email your question to some employee and hope to get answers? How fucked up is that!

Now, my technical issue with SqlCommand is not something everyone will run into. That’s also not the point. The point is: if there’s an issue with the .NET BCL/API, there should be a clear path to the teams working on this codebase to give them feedback, report issues and get things fixed. Today there’s none. Oh of course, if things related to .NET Core pop up, we can open an issue on GitHub and start the conversation there, but this isn’t related to .NET Core: SqlClient on .NET core doesn’t contain any encryption related code (as far as I can tell, .NET Core’s SqlCommand lacks code related to encryption which is in the SqlCommand class in the reference source), so this issue is out of scope for .NET Core. (As an aside, the SqlClient team isn’t really responsive on .NET Core issues either, e.g.  #1039 or #3480)

Microsoft seriously has to get things fixed in this area. We .NET developers now have no way to give feedback to them regarding APIs we have to work with every day. It’s not sustainable nor reliable. I don’t need the email address of the SqlClient team, I need a publically available system where I can file issues and Microsoft can respond swiftly to them so I can tell my clients and customers why things are the way they are. Which is how we do things in the ISV world: give support to our paying customers quickly and fully so they can help their customers quickly and fully. You know, as professionals.

What Microsoft currently ‘offers’ is a sign which says ‘back in 5!’ although the sign is up there for a long time.

5 Comments

  • +1 on Connect being a *terrible* resource!!! And yes we are running into a "when worlds collide" problem here. Easy enough to ping GitHub for .NET Core, but otherwise you are stuck (cursed) with the old-world way of doing things. Hopefully your well-written plea will help turn some wheels towards improvement.

  • Oh man, don't get me started with Connect. I've had so many bad experiences with trying to give feedback on Connect it's ridiculous. I guess I've had a little better luck with getting some response and even getting some things fixed, but the request/response cycle was always measured in months. It also depends on the team - I think the ASP.NET team was much more responsive than the .NET system teams. Regardless though more often than not I've skipped giving feedback on bugs, because it's such a fucked up process. Their loss IMHO. Then again nothing new right? This has been done that way since before .NET existed.

    But you should give some credit where credit is due. At least for the new open source stuff things *are* different and IMHO much improved. I do think that having GitHub at least for the new going forward stuff is a good thing. Everything I've submitted on GitHub has been responded to in a timely manner. Not always to my liking :-) but there is discussion sometimes in real time - and that's the way it should be. I've been talking with the devs working on that particular feature as they're tasked to watch Github for their part of the stack.

    Ultimately that's a big improvement on the definitely crappy experience you describe and we've lived with for so long. Let's not give MS a hard time for doing that part right at least :-). Now as to Connect - we can hope that in the not so distant future either .NET Full will also open up and go OS (although I doubt that - there's gotta be way too much crappy code for Microsoft to want to make that public) or at least move the Issues to Github which would be an easy win IMHO. Of course if the code isn't tied to the same repos, having that developer to issue connection but I'd take anything to get away from that awful input form they use with 20 irrelevant items that have to be checked. I like you won't file another Connect issue ever again.




  • @Rick Strahl

    Regarding GitHub, sure a lot of MS personnel is doing great there, but especially the data stack, it's terrible: all the data classes are owned by the SQL Server team, and they don't use GitHub at all. Sporadically someone went into the issues and replied to a couple of them and then went dark for weeks.

    With ASP.NET it's obviously different, but for BCL classes, especially in the data stack, it's a terrible experience still. I know they're trying to make this better, but it's not really new stuff: every ISV out there knows what to do with respect to support, it's not as if they have to re-invent the wheel.

    I think with the positive experience with the GitHub repos that do go well, it's even more clear how crappy Microsoft's customer support really is regarding full .NET.

    I fully agree, if they at least open a .NET full issue repo for just the issues, it would be a big win already, with the requirement that the teams working on the code bases of course participate in the discussions there :) It's useless if the community debates among themselves how to solve a bug if the people who can actually solve a bug or change an API aren't there. :)

  • At https://support.microsoft.com/en-us/allproducts the .NET Framework link goes to .. .NET Framework homepage :)
    Also https://support.microsoft.com/en-us/gp/contactus81?Audience=Commercial&SegNo=4 is not too useful..

  • Back in 5 minutes.If not back within 5 minutes, read this sign again.

Comments have been disabled for this content.