Whenever you implement "runat='server'" on an element, ASP.NET creates a unique id. 

     id='myControl' ... becomes ... id='ctl00_cphBody_deepWithin_anotherCtl_myControl'

I'm certainly not complaining, abstraction is great, but when you're using the ID as a selector in jQuery, you'll quickly run into issues with Server Controls.  There are a couple of ways, which I can think of, to get around this problem, both have their pros and cons.  

Server Tags

Providing your jQuery is on the same page as your server controls, you can use server tags to write the UniqueID to the page at runtime.

  $("#<%= myControl.ClientID%>").

The problem with this solution is that any jQuery written in external files can't implement it.  Though it would be my opinion that hard-coded ids in external files is bad design, though I'd welcome arguments against that statement.

Wild Card Selecting

An alternative way would be to use jQuery's wild card selection.

   $("[id$='myControl']");

With the wild card selection you have to consider a couple of things.  First off, ASP.NET uses this unique id to ensure that when you nest controls within controls there's no mismatch of ids, so uses a wild card could create bugs, depending on your project.  Secondly, you must consider performance; jQuery is having to search through all elements in order to find your control and no matter how good the algorithm is, it must mean a performance hit.

If you're connecting to services with Silverlight then chances are you'll use either the WebClient or the HTTPWebRequest.  There's a ton of articles out there about implementing both objects but I wanted to cover a few things that I've learned the hard way in the hope that you won't have to.

WebRequest VS WebClient

So which one do you use?  Well, WebClient is a more abstracted object, with WebRequest under the hood, so it really depends on what you need to do.  For simple uploading of a string, then WebClient is just fine, but if you want to get into changing headers, or uploading binary data then you'll probably need the WebRequest.

ClientAccessPolicy.xml

As Silverlight is a client-side framework, it can’t just go crossing domains as it feels like, so to allow access for a Silverlight application, you must have this file on the root of your domain.  If you haven't heard of this before then memorize it now!  Click Here to read up on it and get a sample of the default settings for this cross domain config file.

HTTPCodes 

HA!  You got me Microsoft!  You got me good!

There's only two codes in the WebResponse object, StatusCode.OK & StatusCode.NotFound with Silverlight.  "OK" is equivalent to HTTP status 200 and "NotFound" covers the rest ... well isn't that handy! 

But here's the kicker ... if you receive anything other than a code of 200 then you'll be unable to read the response from the response stream. 

I haven't got a firm answer on the behavior here, but I've certainly come across other people that have had this problem.

So if you're setting the response codes on the service to be specific to what's going, with an error message that you need to read out of the body ... then you'll need to rethink your approach.  Otherwise you won't be able to read the response out of the response object.

Binary Data

One thing that I've come across that I think is important to note is trying to read binary data out of a stream in Silverlight.  For the most part you'll use "StreamReader" to read the response streams out of the Response object. 

However, with binary data that doesn't work very well.  StreamReader is just meant for reading text, so you'll want to use a "MemoryStream" instead.  The code is the same as when you're reading text out of the response stream with a "StreamReader".

QueryString & Special Characters

If you're sending parameters to a service using the QueryString then you might need to think about special characters, especially if you're dealing with user input.  In this case you're going to find that special characters will cause all sorts of problems if you don't encode them first.

Here's an example of encoding your querystring parameters, it must be noted that you should only encode the data for the querystring and not the whole querystring itself.

---

Living to Code != Coding to Live