Entity Framework 5 to 6.0.1 Upgrade SqlProviderServices Exception

Today, I decided to update my Entity Framework (EF) 5.0 NuGet packages to EF 6.0.1. No problem updating; NuGet did its duty, as usual. However, a great number of the Model project tests failed, and executing the application threw an exception, as expected:

The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider 

with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. 

See http://go.microsoft.com/fwlink/?LinkId=260882 for more information.

As usual, the link provided minimal assistance. With a little prodding, I found a workaround for the issue.

The goal of this post is to make as few modifications to the code base as possible, to make the EF5 to EF6 upgrade. Sure, there are some differences between EF5 and EF6 implementation, but we're ignoring that for now. EF6 does not require data provider configurations in the App.config file. The new ProviderService types, embedded in the System.Data.Entity.(ProviderName) namespace does this for us. But, these are the objects giving us trouble. First things first...

Versioning RESTful Services

As I was explaining Representational State Transfer (RESTful) Service Oriented Architecture (SOA) to my customer, who require extensive modernization of an enterprise class system, they asked a very good question:

"Things change over time. If everything is service based, how do we handle versioning of the services, without client disruption. When one applications suddenly requires different information, we can't update all of the other client applications just to accommodate the needs of the one. We also should not be duplicating services fo every client that needs something slightly different."

Excellent question! There are myriad reasons to update a service, but only three major courses of action to follow. One of the three will be a best fit for each situation. Sometimes, things are just that easy. The options are few; because, the ultimate goal is to maintain integrity of the URLs. You simply don't want your service URLs changing, for many reasons into which I will not delve in this post. (If you are reading this post, you should know well enough to be nodding in agreement, anyway.)

To be clear, this post covers RESTful services, such as Web API, and not traditional WISDL-based Web Services or object serialization proxy services, like WCF. No, we're talking true REST.

Visual Studio 2010 Code Compare Line Length Limitation

The default code differencing / compare tool in Visual Studio 2010 contains a bug: lines of code over 4095 characters overrun the buffer and are not evaluated, nor do they appear. What concerns me is that the compare tool did not alert the user that a buffer overrun may have occurred.


Today, my colleague noticed a line of edited code missing from the default VS2010 code differencing / compare tool, used to locate changes in source controlled files. The edited line of code simply did not appear in the tool, and had no indication of containing a change.

Looking at the code in the editor, I noticed it was a wide line. Very wide. 5057 characters wide, to be exact. The code in question was produced by a meat grinder conversion of a legacy system, not only evidenced by this wide line of code, but also that this line was a call to a method that contains 218 input parameters. (Yes, the application actually runs.)

Inserting a line break after character 4095 confirmed this is a buffer overrun issue; breaking the line at character 4095 causes both lines to appear in the comparison tool, and to be marked as a change.