Microsoft Silverlight 4 Data and Services Cookbook

Alas I find my self doing another book review... its not clear to me that I should continue to do that but on this particular book it heads in the right direction. As noted in an earlier post I find the idea of a cook book to be of particular interest and useful in my work with Silverlight. This book has gotten closer then any other to date in building the ideal Silverlight book. Albeit the book does make an attempt to teach Silverlight to some degree but it tends to be more of a reference book, the down side is that there is more in the book about teaching and less about more esoteric topics not connected to data. Certainly though for the professional Silverlight developer this is a great addition to your library.


http://www.packtpub.com/microsoft-silverlight-4-data-and-services-cookbook/book/mid/130510v8s5cu?utm_source=hackingsilverlight.blogspot.com&utm_medium=affiliate&utm_content=blog&utm_campaign=mdb_003316

Xaml WCF Binding Type

Just kidding... as of late I am not aware of such a think however, it could be done. I was pooring over the great project in outer darkness I'm working on and Karim sitting near by was talking about using Xaml as Clr Object markup and Xaml Reader. In joking about it came up to use Xaml as and WCF binding type. Eventually we got to a more serouse topic about the limitations of WCF support in Silverlight event Silverlight 3. In any case John Papa's book on data driven services with Silverlight 2 is probably the best resource on the topic as of late and John did quick post recently on Silverlight 3 and bindings supporting in Silverlight 3 which includes binary support which would be made in some 'Xaml' hack :)

http://johnpapa.net/silverlight/wcf-binary-bindings-in-silverlight-3/

RPS in Silverlight

first of all I'd like to say that this is going to be a bit of a rant... second, it is my opinion that RPS in general is a giant hack. it is easier to just build your own security infrastructure from the group up then use RPS in my opinion...

That being said at times this has been a requirement. As far as using RPS it is not that difficult once you get past configuration and fairly straight forward to use in Silverlight. In my case I'm currentlying working on a project that shall rename unnamed where it was a requirement to use RPS.

RPS has this thing called a ticket that we pass around to make sure a user is logged in. We had this WCF services we needed to secure as well that the Silverlight application is talking to so we needed to get the ticket up on the client Silverlight app so it can be passed on the WCF calls todo authenication with live id. So once it was working ASP side all we needed todo was seriealize the ticket by using its token or RPS Token value and passing that as a parameter into our Silverlight application.

Then on the root of the app we save this RPS Token value to be used in authentication on the WCF calls.

Great. right?

Wrong...

this all worked fine and about a week in we the ticket type in test changed. one would think ok waht did we do wrong. apparent now we had to authenticate using type 2 in stead of type 3... WT...??? Some time later it changed to 4 and now we have to use 3 again. oh but we have changed anything about around the RPS Tickets? so what is up?

granted this was also a developement system and not hitting the 'live' live id system but still and another guy I know was working on a different project and they hit the same problem. As a joke I finally added this block of code:


StringBuilder WTFErrorList = new StringBuilder();
RPSTicket MyTicket = null;
for (int x = 1; x < 11; x++)
{
try
{
MyTicket= MyAuth.Authenticate(m_RPS_AppName, rpsTicket, (uint)x, propBag); // !!! WTF???
break;
}
catch (Exception E)
{
string WTFErrorMessage = x.ToString() + " WTF Error[RPSSupport::ValidateTicket] " + E.Message;
WTFErrorList.AppendLine(WTFErrorMessage);
WTFErrorList.AppendLine("m_RPS_AppName: " + m_RPS_AppName);
WTFErrorList.AppendLine("rpsTicket: " + rpsTicket);
WTFErrorList.AppendLine("");
Debug.WriteLine(WTFErrorMessage);
}
}
MyTicket.Validate( propBag );

The down side is this will never fly in production with all the code reviews but in got me over the humpe of figuring out what ticket type to use...

WCF and Silverligth 2 - Beta 1 and automated builds

One issue I ran into recently was the fact that currently the Silverlight 2 autogenerated client code for WCF services is autogenerated. This is not a big deal typically, but here is where I found some issues... (actually it wasn't me but this guy Sina that found the problem and some one on Mike H's team that explained it) but this is what was found.

We are doing this pretty big silverlight application that is pretty much a shrink wrapped quality solution. Part of the implementation of this is a complete automated build system for QA and part of that was the fact that the production environment is a huge hands off big no touching sort thing.

In this particular application we have a number of WCF services that we are talking to, that are local in the web solution along with the silverlight application. When you run this in Visual Studio it works well. When we deployed it we noticed we had to deploy the solution, re do the references to the deployed WCF service and then deploy again. a bit of a pain but in and automated scenerio using msbuild and the like and you have no idea what the url will be, this is extremely problematic.

We also found a nice service client config file with the url settings for the server etc in the compiled xap but when changed this didn't seem to do anything. Much to our sadness we found out that we might look for this in the next version and the file though created was ignored. The solution that hopefully will go away in Beta 2 is to over-right all our constructors and pass in a value we configure in the web.config... Basically something like this:

ServiceClient MyClient = new ServiceClient( new BasicHttpBinding(), new EndpointAddress( new Uri(SomeConfigValueAsString)));

basically overright which constructor is used and pass in the value that would normally be compiled directly into the dll. A hack I know but it works until we get that beta 2 and we can still use our WCF service.