Tuesday, August 4, 2009

Adventures while building a Silverlight Enterprise application part #18

Talking about ups and downs. Today we look into an issue with upgrading from Silverlight 2 to Silverlight 3. I feel Microsoft did drop the ball on this one and I guess not a lot of developers noticed it so far as I didn't get any helpful feedback on silverlight.net.

But first I would like to share with you, my first ever interview (ok, so it's only online, but hey, I'm not a famous blogger, right?). You can read it here. Thanks, BenSpark, for giving me this oppertunity.

So, down to business. Here is the complete story. At first it may not seem very relevant, but hang in there.

It all started back in december 2008, when Microsoft released a seperate update for the datagrid in Silverlight 2. We chose to install it, as it fixed an issue we had with the datagrid in combination with the combobox. Installation of this update involved replacing System.Windows.Controls.Data.dll in the Silverlight 2 SDK folder with a new version and then recreating any existing references to it. We went trough the steps and all worked fine so I completely forgot about it after that.

Now about two weeks ago, after testing our application code with Silverlight 3, our product team decided to go ahead and upgrade to Silverlight 3. At that point I was alone working on the Siverlight solution, so I went ahead and upgraded my machine to Silverlight 3. I loaded the solution and it upgraded without any issues. I checked in the solution to Source Control and went on with working on different parts of the application.

Last week a colleague was getting ready to work on the Silverlight solution as well, so he installed Silverlight 3 on a clean VM and loaded the solution. He tried to build, but it failed because it couldn't resolve the reference to System.Windows.Controls.Data.dll. We didn't think to much of it and recreated the reference after which everything worked fine. He ran the application and nothing seemed wrong so he checked in the solution.

I figured I would get the latest version from Source Control, to make sure everything was still working, but it wasn't. Sure, it build and I could run the application, but one of my datagrids, was now not showing any data inside the records (so it did show records). Here is what I saw in the grid:


As you can see the alternating background colors show to records are there, but no data is displayed. Breakpoint on the getters of the properties bound to the columns didn't get any hits, so something more complex is obviously wrong. The code didn't change so that couldn't be the issue. I dough into this and spent almost two days on finding out what was wrong.

Eventually I decided to fire up the VM I used for testing the upgrade and compile my source in there. It did show exactly the same issue, but as compilation was a lot slower I noticed in the output, this one line (click the image to enlarge):


As you can see it states a conflict between versions of the System.Windows.Controls.Data.dll's in different projects. The end of that line actually states:

Choosing "System.Windows.Controls.Data, Version=2.0.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" arbitrarily.

What?? I don't like that at all. It doesn't know anything about these assemblies and just gambles to pick one. I feel a compiler error would be in place here, telling me to resolve the conflict manually. Ok, one could argue that it did actually get the Silverlight 3 version (the public key token is the one from Silverlight 3 and not 2). However, it may very well load the wrong dependencies as I assume it did in this case, causing strange behavior. Even stranger, I checked the project files XML and found out it actually explicitly references the Silverlight 2 version, including it's public key token, so why didn't it reference that one?

What do you think about this? Please leave me a comment below.

I decided to recreate the reference, so it would now point to the Silverlight 3 version. I rebuilded the solution and now it works! The conflict is actually resolved, so it no longer comes up in the build output. The datagrid shows the records it's supposed to show.

Lessons learned:
  • Read the build output when in trouble
  • If possible avoid manually updated assemblies
  • Don't trust that if it works on one machine it will work on other
So now that frustrating problem out of the way, it's back to the daily work.

No comments:

Post a Comment