Linq2Xsd : Why are you doing this to us?

Mar 3, 2009 at 9:17 PM
Edited Mar 3, 2009 at 9:19 PM
I'm in the process of upgrading my code to use version 2.0 of the FDT, and I'm really distraught that you've chosen to rely on Linq2Xsd.  You know that it's a dead project, right?  Don't believe me?  Here's your proof.

In version 2.0, you changed everything.  And by everything, I mean everything.  You didn't just shuffle the namespaces around.  You changed basic elements of functionality.  Because of this, upgrading is a serious pain.  And while I don't relish this task, it wouldn't be so bad if I thought I was only going to have to do it once.

However, you've decided to make your library dependent on Linq2Xsd, which is a dead project.  What are you going to do in future releases of the FDT?  Are you going to continue to rely on a dead project that never made it out of alpha?  Or are you going to introduce yet another round of sweeping changes, causing myself and others to go through the rigermarole of refactoring our entire codebase yet again?

The FDT is an integral part of my company's applications.  I can see that over 20K people have downloaded the latest version of the library, so presumably we're not alone in depending on you for a crucial piece of our business.  When I see that you are relying on a dead, half-baked component, it shakes my faith in your company's ability to produce a reliable library.  It makes me think that I shouldn't be bothering with your library at all, and that I should in fact "go it alone" and develop my own API wrapper.  The thought has certainly crossed my mind.

I demand an answer.  I need to know where this project is going; my business depends on it.

Mar 4, 2009 at 7:58 PM
Edited Mar 4, 2009 at 8:18 PM

The goal of 2.0 of the toolkit was to better respond to (regular) changes in the facebook api and better align the toolkit’s api with facebook’s.  It was understood we’d break old code in order to better mesh with what facebook has published in its api.  We solicited feedback before we began development.  The community up-voted what features they’d like to see and we worked those items. 

In order to better respond to changes in the API, we looked into tools that would do the monotonous heavy lifting that was required for all previous updates.  We found what we needed in Linq2XSD.  When evaluating Linq2XSD, our goal was to find a framework for creating entity objects, and parsers based upon an xsd. For more information about Linq2XSD, look at Scott Hanselman’s take on the project

We are not using very much of the “Linqiness” of Linq2XSD which you linked to or that others use.    We’re only using it for the object creating and parsing.  When talking with the Microsoft team about the stability of this piece, they felt it was stable enough for what we’re using for.  An alternative option was to use  XSD.exe which is an old tool that is able to create the entity objects, but we would have had to create our own parsing engine for each object, forcing us to write our own parsing anytime Facebook  changes their API. This would have defeated the reason of creating version 2.0 of the toolkit: to make it easier for the community to respond to changes to the Facebook api.

Additionally, we are provided flexibility going forward in how Linq 2 XSD generates its entities.  It does leave its generated code for entities and parsers available for us to modify if we ever need to at a future date.

The goal going forward is to stay as close to the facebook api as possible with the toolkit.  This allows the toolkit developers to “talk the same talk” as those developing natively against the facebook api, allowing all users to post the talk about issues in the same forums and get help from all.

If this product is such an integral piece of your business, I suggest (for your own sake) you become a codeplex developer on this project.  I’ve stated this before in previous postings, but there is a reason this code is hosted on codeplex, not on Microsoft’s site.  We made these changes so that the community can help us update this toolkit as facebook changes its api.

 - Peter



Mar 4, 2009 at 8:05 PM
Edited Mar 4, 2009 at 8:06 PM
Peter -

Thank you for your prompt response, and thank you for the insight into the workings of the FDT.

However, my main question still hasn't been answered - what about the future?  It looks like MS is abandoning Linq2XSD.  Do you plan on moving away from Linq2XSD at all?  If/when you do, will there be huge breaking changes like there were going from 1.7 to 2.0?

Finally, I'm going to ask this because it's been bugging the heck out of me.  Why in the world did you change UID from a string value to a long?  Having the value as a long instead of a string doesn't give us any sort of improved functionality; it's not like we're going to add or subtract UIDs or anything.  However, changing this value from a string to a long required me to make significant changes to my code, all the way down to the database level. 

Mar 4, 2009 at 8:18 PM
I guess the short answer is, “We’ll cross that bridge when we get to it”. 

We’ll continue to use linq2xsd as long as it still provides us with the simple entity generation and parsing.  If future versions of the xsd break for us, we’ll have to look into other tools that might exist at that time, E.G Use xsd.exe, and use the xmlserializer class to populate these objects by hand.  To use another saying, “If it ain’t broke, don’t fix it”.

That being said, I don’t anticipate breaking the api again if we have to make changes to our entity generation and parsing, as we really just “fixed a bug” with v1 of the toolkit abstracting the api too much at the cost of ease of maintenance.
Mar 4, 2009 at 8:24 PM
Huh.  Ok, well, thanks for answering my question.  Apologies if my initial message came across as unnecessarily angry.  It's just a little frustrating because this upgrade is taking a bunch of my time that I'd rather be spending improving my apps.  And while I understand that you felt these changes were necessary, having to completely refactor my code does make me ask myself the question, "why am I using this library again?"  I'll go ahead and upgrade to 2.0, but if the next upgrade is anything like this, we may have to part ways.

I'm still curious as to why you changed the UID to a long value.  What a pain.
Mar 4, 2009 at 8:43 PM
I don't specifically remember that conversion, but I believe we tried to be as close to the FB api as possible, therefore keeping types the same also.  I'm surprised you need to make changes all the way to the DB.  You could still use a string on your side, e.g. converting it to a string before you passed it to the db. 

Mar 4, 2009 at 8:49 PM
Yeah, I thought of doing a bunch of explicit conversions, but that's kinda kludgey and I try to avoid stuff like that.  Oh well, I guess I'll just suck it up and deal.
Jun 24, 2009 at 7:17 AM

Is this the right version of Linq2Sql that I need to build the source?

Is there anything else special I need installed?


Jun 25, 2009 at 1:46 PM

You shouldn't need to download anything unless you plan on re-generating the xsd classes.  All you should need is the assembly Microsoft.Xml.Schema.Linq.dll.  This is in our Binaries zip and also in source.  You just need to reference this assembly and you should be good to go.


As an FYI- We are getting rid of Linq to XSD in 3.0 for a similar approach but one that does not require an extra assembly ref and one that will work in Silverlight.



Jun 25, 2009 at 5:10 PM

Microsoft.Xml.Schema.Linq.dll is not contained in any of the 2.1 releases. It's not in the binaries, source or samples downloads.

I did find it in 2.0 binaries.

Jun 26, 2009 at 1:37 AM

Looks like I got the wrong binaries somehow. It's in the 2.1 release.