So, it's been a good while since my last post. It's been a crazy several months and time has been scarce to devote to blogging, but my situation has changed and I'm back in the saddle.
After spending the past couple of years working on .Net 2.0 project, I've spent the last few months playing catchup on some of the latest fodder to roll out of Microsoft...Linq, Silverlight and WCF. I have a long way to go on each, but with time and a bit of effort I should be caught up in good time. As is my usual style, I'll be posting about the stumbling blocks I encounter and how I managed to either solve or mitigate them. This first post concerns a problem I faced working with WCF services from a Silverlight project. Here are the details.
Being a newbie to Silverlight, I cruised over to Microsoft's Silverlight web site, watched the videos and read the tutorials before getting started. I felt I had a pretty good grasp on things and started work on an idea I had. I created a Silverlight project and allowed Visual Studio to create a web project for me, as well. I, then, added a third project to host my service layer which would be made up of Linq to Sql calls, so I also created the dbml file, there, that represented my database. The idea was that the Silverlight project would call WCF services hosted in the web project which would in turn call methods in the Service layer to query and effect changes in the database.
I started work and created several methods on my WCF service. Each time I added functionality to the service, I would right-click the service reference and select "Update Service Reference" to allow the new methods to be generated in my proxy (I'm aware that using Visual Studio to generate WCF client code is emerging as an anti-pattern. I will, at some point, replace the generated code with code of my own creation...stay tuned for more on this). After several days with no problems, I repeated this process again and had several warnings raised saying that no proxy could be generated and that my service was not Silverlight compatible. Hmmmm.
I rechecked all the classes I was sending over the wire to make sure the right serialization attributes were present. I ran svcutil.exe against my service and it generated a proxy, just fine. As a last ditch effort, I recreated the web project tried again only to have the problem reoccur. I was truly stumped. So, I reverted my service reference code to a good state and continued to look around and found nothing until I had a revelation. When you right click the service reference, there is an option to "Configure Service Reference". This opens a dialog that allows you to tweak the settings for the service that control what generic classes among other things.
In the lower part of the box, you are allowed to chose which types to reuse. Best I can tell, this reuse involves serialization since the types would be "reused" on both sides of the service binding. Upon inspection, I found that some Telerik assemblies were included in the list. If I chose the lower radio button and unselected the Telerik assemblies, my service reference was generated properly. Apparently, some of the types in one or more of these assemblies could not be serialized.
This is an example of the kind of thing that can happen and the frustration it can cause when you know just enough about a technology to be dangerous. I'll be working hard to remedy this in the coming days.