Entity Framework 4.1 Update 1, Backward Compatibility and Microsoft
One of the things that you keep hearing about Microsoft products is how much time and effort is dedicated to ensuring Backward Compatibility. I have had a lot of arguments with Microsoft people about certain design decisions that they have made, and usually the argument ended up with “We have to do it this was to ensure Backward Compatibility”.
That sucked, but at least I could sleep soundly, knowing that if I had software running on version X of Microsoft, I could at least be pretty sure that it would work in X+1.
Until Entity Framework 4.1 Update 1 shipped, that is. Frans Bouma has done a great job in describing what the problem actually is, including going all the way and actually submitting a patch with the code required to fix this issue.
But basically, starting with Entity Framework 4.1 Update 1 (the issue also appears in Entity Framework 4.2 CTP, but I don’t care about this much now), you can’t use generic providers with Entity Framework. Just to explain, generic providers is pretty much the one way that you can integrate with Entity Framework if you want to write a profiler or a cacher or a… you get the point.
Looking at the code, it is pretty obvious that this is not intentional, but just someone deciding to implement a method without considering the full ramifications. When I found out about the bug, I tried figuring out a way to resolve it, but the only work around would require me to provide a different assembly for each provider that I wanted to support (and there are dozens that we support on EF 4.0 and EF 3.5 right now).
We have currently implemented a work around for SQL Server only, but if you want to use Entity Framework Profiler with Entity Framework 4.1 Update 1 and a database other than SQL Server, we would have to create a special build for your scenario, rather than have you use the generic provider method, which have worked so far.
Remember the beginning of this post? How I said that Backward Compatibility is something that Microsoft is taking so seriously?
Naturally I felt that this (a bug that impacts anyone who extends Entity Framework in such a drastic way) is an important issue to raise with Microsoft. So I contacted the team with my finding, and the response that I got was basically: Use the old version if you want this supported.
What I didn’t get was:
- Addressing the issue of a breaking change of this magnitude that isn’t even on a major release, it is an update to a minor release.
- Whatever they are even going to fix it, and when this is going to be out.
- Whatever the next version (4.2 CTP also have this bug) is going to carry on this issue or not.
I find this unacceptable. The fact that there is a problem with a CTP is annoying, but not that important. The fact that a fully release package has this backward compatibility issue is horrible.
What makes it even worse is the fact that this is an update to a minor version, people excepts this to be a safe upgrade, not something that requires full testing. And anyone who is going to be running Update-Package in VS is going to hit this problem, and Update-Package is something that people do very often. And suddenly, Entity Framework Profiler can no longer work.
Considering the costs that the entire .NET community has to bear in order for Microsoft to preserve backward compatibility, I am deeply disappointed that when I actually need this backward compatibility.
This is from the same guys that refused (for five years!) to fix this bug:
new System.ComponentModel.Int32Converter().IsValid("yellow") == true
Because, and I quote:
We do not have the luxury of making that risky assumption that people will not be affected by the potential change. I know this can be frustrating for you as it is for us. Thanks for your understanding in this matter.
Let me put this to you in perspective, anyone who is using EF Prof is likely to (almost by chance) to get hit by that. When this happens, our only option is to tell them to switch back a version?
That makes us look very bad, regardless of what is the actual reason for that. That means that I am having to undermine my users' trust in my product. "He isn't supporting 4.1, and he might not support 4.2, so we probably can't buy his product, because we want to have the newest version".
This is very upsetting. Not so much about the actual bug, those happen, and I can easily imagine the guy writing the code making assumptions that turn out to be false. Heavens know that I have done the same many times before. I don’t even worry too much about this having escaped the famous Microsoft Testing Cycle.
What (to be frank) pisses me off is that the response that we got from Microsoft for this was that they aren’t going to fix this. That the only choice that I have it to tell people to downgrade if they want to use my product (with all the implications that has for my product).
Comments
I just don't unserstand, why they did that "voodoo string manipilation"
And it isn't possible that anyone on EF team tested this new version with EfProf or any other wrapper like that sample on Microsoft Msdn that make profile and cache
Is the solution an easy fix? If it is, then post the solution online and let's get something rolling to get Microsoft to accept it (in a nice way). EF is getting better, but the versioning is kind of wonky. As an EF user I definitely fear breaking changes with minor upgrades. Thanks for the informative post.
Ugh. That's a MS failure. Period.
Is there a connect issue for this? You can certainly get all of your customers (and blog readers) to vote on the issue.
MS was doing so well. They were changing there ways, then they go pull a stunt like this. Not cool at all.
Khalid: my post on the same issue (linked in the blog above) has a small piece of code which Microsoft can use to fix it (it's for them very easy to fix).
For us profiler writers (e.g EF prof or our own) and others who try to integrate into EF using the factory, it's not easy to fix. The only thing I could come up with was generating wrapper classes in memory and compile them in-memory into separate assemblies, which would make the method inside EF work again, but it will always have a 2-3 second penalty due to the compiling of the separate assemblies.
That's the sucky part.
The lack of proper extensibility points makes EF tough to work with on a number of fronts. This is just another example of ivory tower thinking. Let's hope the EF team is listening and does the right thing because UberProf is an essential tool for teams using ORMs to learn how to use the ORM properly.
Oren, now you should use the code that I'd sent to you :)
Ugh. It's sad that MS is more and more going this way. Not fixing bugs. Customers and top management often require the use of MS tools, because "it's crucial to have the support". I usually respond that that support is what is lacking. You are much more likely to get support or a fix to a problem when using open source or 3rd party vendor tools.
@Rob
+1
@Ayende
Whatever=Whether
Does Microsoft even do anything with Connect issues? This isn't meant to be funny, I've just seen many legitimate issues on MS Connect that have been ignored.
I don't use MS Connect as I was scared off just reading their terms of service. The final outcome here isn't in stone hopefully someone on the MS side hears your plea and does the right thing.
EF is a terribly engineered product. Because MS has tried and failed so many times to create a decent ORM layer, it's probably become this bastion of politics and in fighting.
I found a bug on Excel because I was developing an application for it using VSTO. I informed MS about the bug, they confirmed it, but I have no perspective to see it fixed because it doesn't happens to normal Excel users and I don't have the necessary level of relationship with MS. I understand that as, "you're not a gold partner or above" or "you didn't buy 2000 Office copies".
The problem is killing my application because it has relation to copy & paste. Is there anyone that don't use copy & paste on Excel?
I asked about fixing this bug on the ADO.NET blog in the comments: http://blogs.msdn.com/b/adonet/archive/2011/08/04/code-first-migrations-your-feedback.aspx
Their response was encouraging: "We are working on the logistics of the fix for that issue at the moment, we'll post up our plans shortly."
I do not understand the full technical issue, but maybe you can get around it by generating an assembly at runtime containing a single type:
class Wrapper : rofilerDbProviderFactory<XXX>.
Set XXX at runtime.
Oh god why do you strip HTML? Just encode it which almost always is the correct way.
class Wrapper : ProfilerDbProviderFactory[System.Data.SqlClient.SqlClientFactory].
Tobi, Probably you run into the safety filters. At any rate, yes, we can do that. The problem is that we can do that only for a single provider, and there are dozens out there. Another piece of code in EF now ensures that there can be only a single provider per assembly.
Well they can't fix it now, it's too late - it wiuld break backward compatibility with EF 4.1u1...
I have found that Connect is a great place for 'tracking' an issue, but if you want to get traction, you need to find someone within Microsoft who can champion the issue on your behalf. If you are able to do this, and the issue requires only an isolated modification, then you can get a QFE in more reasonable timeframes.
I say 'more' reasonable, because the definition of 'reasonable' obviously depends on the severity of the issue.
My last QFE turnaround (from initial report), was approximately 12 months.
@Adam - That is pretty quick - I had a grievous application error in one of their ERP-products (An insert trigger was fired for every row returned by a query - leading to odd results as well as crippling performance). That took 2 and a half years before they said: "We'll fix that in a version that is scheduled for either 3 or 5 years from now"... I wouldn't hold my breath for Connect to shine...
To me, there need to be two fixes deployed to the community for this:
Fix 1) Remove this regression and fix the bug
Fix 2) Fix whatever allowed a breaking change in something that isn't even a minor version or service pack... it's "update 1".
That's just for this issue, of course. Separately, they must fix the versioning "strategy" that forces us to track things like "4.1u1 has feature X while 4.1sp1 does not".
Just fork it on github! duck
Hm, i wouldn't shout that loud. Look at the current NH 3.2 release it is'nt so much better...
Good to see that this bug is being fixed as we speak:
http://blogs.msdn.com/b/adonet/archive/2011/08/11/next-ef-release-plans.aspx
And here's a link to the beta for anyone who didn't just come here to whine and not return to say "hey, gotta give them credit...they did the right thing this time":
http://blogs.msdn.com/b/adonet/archive/2011/08/22/ef-4-2-beta-1-available.aspx
Comment preview