Get A Silverlight Control's Current Instance For Communicating Via The HTML Bridge

If you have a SilverLight control on an ASP.NET webpage, odds are eventually you will need to communicate with it, and this is done via JavaScript and the HTML Bridge. However you might find that the accessing the control's current state after user manipulation is not as straight forward as the documentation from the MSDN indicates.

In the MSDN and most examples, the suggestion is made that you explicitly register an instance of a scriptable type (your control's class) in the App class or the Page class. However there is a big difference on these (2) and also in the exact instance that you choose to register.

If in my control the main class is named 'MySLControl', so I decide to register its type in the 'Application_Startup' event of App.xaml like below:

Dim _MySLControl As New Silverlight.Custom.MySLControl
HtmlPage.RegisterScriptableObject("SLControl", _MySLControl)

The above will work perfectly and you will then be able to access your exposed <ScriptableMember()> types from JavaScript. However, there is a catch - the registered instance is a New instance of MySLControl so it will not contain the state of the control when called by JS.

So let's say you have a custom built online MP3 player you built with a 'Playlist' created by the user within the control. You want to use the HTML Bridge from your hosting ASP.NET app to communicate with the control and get some details on the playlist. If you access the registered control instance as coded above, you will not have access to any of the control's state after the user has interacted with it. Why? We registered a New instance and are not using the actual control's instance.

The change is (2) fold: First, move the registration of the type to a late event in the Page (control) itself like a wired up 'ControlLoaded' event as typical for many Silverlight controls. Second, register the current instance of the control and not a new instance. The code is displayed below:

Private Sub ControlLoaded(ByVal sender As Object, ByVal e As RoutedEventArgs)
   'Register this control type so it can be accessible via JavaScript.
   'This allows other platforms like ASP.NET to have a medium to communicate and raise events within the control.
   'MUST use this instance or the current control state will not be accessible by the JS calling it via the HTML bridge.
   HtmlPage.RegisterScriptableObject("SLControl", Me)
End Sub

The result? When you access your Silverlight control via JavaScript you will have access to the control in its current state including any interactions or manipulation done to the control by the client.

Accessing Instance Properties in Silverlight from JavaScript

I have been messing around with the HTML bridge between Silverlight and JavaScript recently and have a few different posts on this topic that may help others. While those doing Silverlight are starting to see "the writing on the walls" as they say and may become the next technology to 'retire' akin to ActiveX controls from the IE4 days, it is still quite prominent as of this post so topics and discussion on it are well worthwhile.

There are several posts about exposing methods and properties to JavaScript from Silverlight so I will not get into that here. However most of the examples are really 'vanilla' as usual and don't offer more than the basic information.

One thing I wanted to do was access an instance property in Silverlight from JavaScript. There really is no major trick to it and it is as straight forward to access as it should be... for once.

So let's begin by looking at the exposed properties on the Silverlight control below. There is a simple 'String' and then an instance property of 'MyCustomClass' which is the focus of this post. Let's assume 'MyCustomClass' has (2) simple String properties on it: 'Name' and 'Address'.

<ScriptableMember()>
Public Property Description As String

<ScriptableMember()>
Private _MyClass1 As New MyCustomClass
Public Property MyClass1() As MyCustomClass
 Get
   Return _MyClass1
 End Get
 Set(ByVal value As MyCustomClass)
   _MyClass1= value
 End Set
End Property

Next we need to register our class to be accessible by script as well which is shown below. This can be done in the constructor of the control. 'Me' (or 'this' for C#) is my Silverlight control class instance behind the .xaml control.

HtmlPage.RegisterScriptableObject("MySLControl", Me)

Now you *might* think you need to register another member above for the instance property, but you do not need to do that. You can drill down to it through the main class instance exposed as a scriptable member as shown below:

//Get instance of the Silverlight File Upload Control
var SLControl = document.getElementById("SilverlightControl");
if (SLControl != null)
  SLControl.Content.MySLControl.Description = "Blah";
  //Drill down through the instance property exposed on the Silverlight control
  SLControl.Content.MySLControl.MyClass1.Name = "Allen Conway";
  SLControl.Content.MySLControl.MyClass1.Address = "123 Oak Street";

One thing to take note of - notice how I used a long hand property for 'MyClass1' rather than an AutoProperty. If you use an AutoProperty and can't provide an object that has been instantiated for its backing value by default or when setting its value, the JavaScript block will throw an error stating "Object reference not set to an instance of an object" when accessing the MyClass1 instance properties.

That's all there is to it. You can just drill down to the instance property through the registered instance of the scriptable type.

Begin StoryBoard Animation Within A DataTemplate In Silverlight

Animations in Silverlight are a great way to add a dynamic feel to the aesthetics of your Silverlight page or control. Within Silverlight, using a DataTemplate to define a control’s properties and look when a control will be repeatedly used or displayed is the perfect solution. However if you add an Animation to the DataTemplate, trying to set it in motion from the code behind is not as straight forward as it initially seems.

Let's say you have a simple animation and you want it to run when the 'MouseEnter' event fires. In VB.NET, the traditional thinking is to go into this event that is exposed by the created DataTemplate and call 'MyAnimationStoryboard.Begin()'. Guess what though, the app will build, run, hit the event upon having the mouse enter, but the animation will not begin. No exception is thrown, it is just nothing happens.

It turns out that the StoryBoard is only locally known to the object containing it within the DataTemplate, so we must 1st access that control's resources where the storyboard exists, and then we will be able to begin the animation.

So here is a DataTemplate with a Grid control and a StoryBoard. The code is being kept simple because the solution for this is in the code behind.

<DataTemplate x:Key="MyTemplate">
  <Grid Width="100" Height="100" 
       Opacity="0.75"
       MouseEnter="MyGrid_MouseEnter" >   
 <Grid.Resources>
  <Storyboard x:Name="MyTemplateAnimate">
   <DoubleAnimationUsingKeyFrames Storyboard.TargetProperty="(Shape.Fill).(GradientBrush.GradientStops)[4].(GradientStop.Offset)" 
   Storyboard.TargetName="path">
   <EasingDoubleKeyFrame KeyTime="0:0:0.3" Value="0.296"/>
   <EasingDoubleKeyFrame KeyTime="0:0:0.4" Value="0.384"/>
   <EasingDoubleKeyFrame KeyTime="0:0:0.5" Value="0.475"/>
   <EasingDoubleKeyFrame KeyTime="0:0:0.6" Value="0.529"/>
  </DoubleAnimationUsingKeyFrames>
  </Storyboard>
 </Grid.Resources>

 <Path x:Name="path" Data="M0,0L50,0L25,50L0,0L0,50L0,0">
  <Path.Fill>
    <LinearGradientBrush EndPoint="-0.419,0.662" 
   MappingMode="RelativeToBoundingBox" 
   StartPoint="1.051,-0.137">
   <GradientStop Color="#FF18250A" Offset="1"/>
   <GradientStop Color="#FF18250A"/>
   <GradientStop Color="#FF345016" Offset="0.725"/>
   <GradientStop Color="#FF345016" Offset="0.275"/>
   <GradientStop Color="#FF779F4C" Offset="0.5"/>
    </LinearGradientBrush>
   </Path.Fill>
  </Path> 

  <TextBlock x:Name="TextBlock1">        
  </TextBlock>         
 </Grid> 
</DataTemplate>

The DataTemplate does expose the needed 'MouseEnter' event in the code behind but the problem is the StoryBoard is in the child 'Grid' control. Therefore we have (2) options: use the VisualTreeHelper class to find the right child control, or simple define a 'MouseEnter' event on the actual Grid control. I went for the latter option as it is the easiest.

Let's add the event we declared on the Grid in the XMAL named 'MyGrid_MouseEnter' to the code behind. We need to cast the sender which is the Grid itself, and then find the StoryBoard object within the Grid's resources. Once we have acquired and casted the exact StoryBoard, then we can call the .Begin() method.

Private Sub MyGrid_MouseEnter(sender As Object, e As System.Windows.Input.MouseEventArgs)
  'Cast the sender to an object of type Grid, so we can find the StoryBoard
  Dim MyTemplateGrid As Grid = DirectCast(sender, Grid)
  If MyTemplateGrid IsNot Nothing Then
    'Find the StoryBoard by name and then begin its animation sequence.
    Dim StyBrd As Storyboard = TryCast(MyTemplateGrid.Resources("MyTemplateAnimate"), Storyboard)
    StyBrd.Begin()
  End If
End Sub

That's it, run the Silverlight app, and the StoryBoard within the DataTemplate will now run. If the controls in this example were not exactly what you have, the principal is you need to drill down to find the containing parent object of the StoryBoard to then get access to the storyboard. If you need, you can use the VisualTreeHelper to drill down to the proper child control. If you need a sample of using this class please refer to the following link: http://forums.silverlight.net/t/99891.aspx

ASP.NET Web Forms vs. ASP.NET MVC

So it has been a few years now since Microsoft introduced the ASP.NET MVC Framework which is Microsoft's implementation of the MVC Architecture for ASP.NET. No the MVC (Model-View-Controller) architecture is not a new concept; just Microsoft's implementation of it in the .NET Framework. There has been a lot of buzz around whether to continue to use ASP.NET web forms which have been around since 2001, or to go with this "hot" new technology in ASP.NET MVC... or something else! There is no 'Silver-Bullet' answer to this, and with most situations, 'it depends'.

Oh I know, you might have "Googled" the exact phrase of this blog post and were hoping to get some answer to exactly which one is better. Nope. I just want to highlight a few of the strengths and weaknesses of both from an abstract point of view, and briefly mention some other alternatives too.

To begin, I am going to repeat a stat that Andrew Duthie (Twitter handle: @devhammer) brought up on this topic at an ASP.NET Firestarter event in Orlando last December. He showed a stat that somewhere in the range of 80%+ dev shops were still using ASP.NET web forms for their bread and butter applications, and that ASP.NET web forms were not going away! Anyone trying to spread a rumor like that needs to check with the folks direct from Redmond 1st, because it simply isn't true. To this end, folks shouldn't feel like they missed the last train to MVC euphoria because everyone hasn't boarded yet. I am not building up an article against MVC; I just want to point out that it is a misnomer that ASP.NET MVC has completely replaced an outdated web forms architecture that some may speak convincingly of on forums and blogs.

So maybe you are leading a team of developers and are looking to decide the pros and cons of MVC, or maybe you are about to build a site for a friend/family member as fast as possible, or involved in a large scale enterprise application that will be web based. Whatever the scenario, you want to know the details of which architecture to choose. After all it will be quite difficult to change between the two once the code begins to flow. Making the right decision up front is important in any of these scenarios no matter how small or large the project.

Let's 1st speak to the advantages of the MVC framework. 1st and foremost in my book is the Architecture itself: M-V-C. It is going to be tough to break this model and rearrange how the application is built. Having your or your team's hand forced into a stable and mature architecture like MVC is a good thing. Raise your hand (like anyone can see...) if you have ever seen or maybe written one of those spaghetti sandwich ASP.NET web forms application that has raw SQL right behind "btnSave_Click()". Blah! Awful nasty, all code-behind the forms, non-scalable mess of an application. So 'point' to MVC for guiding developers to a decent architecture. You can adhere to several good architectures using ASP.NET, but it is up to the developer or team of developers to be disciplined enough to stick to the architecture and not lay back on a fat UI layer. Separation of concerns is a key Object Oriented Concept and a real winner for the MVC architecture. Each layer has its own responsibility, and placing the proper code in its responsible layer will make for a much better code base to scale, maintain, inherit, etc.

Next ASP.NET MVC allows the developer to have "Full Control" over the rendered HTML. For now I am going to leave this as an advantage for MVC, but caution that not everyone fully understands what this means, and it might not be advantageous for a vast majority of applications not needing this type of control. Let me elaborate a bit; that wonderful winter of 2001 when many of our lives took a turn for the better as Scott Guthrie (Twitter handle: @scottgu) came up with what is ASP.NET web forms, and decided while sipping hot cocoa that if you drug a label onto a web form, it would get rendered as a DIV tag. He made this decision (or Microsoft) and not you. You pick the ASP.NET server controls you want to drag onto a web form, but don't have control over what HTML elements actually get rendered on the client as a result. You just know that when a Gridview is dragged onto a form, it will be displayed on the client. You don't know (or need to in many situations) that it might be a series of DIVs and Input HTML controls. This abstraction is actually an advantage for ASP.NET web forms. For many web applications built, we have relied on this drag and drop capability, and trusted the final output that will be rendered to ASP.NET. However, if you have ever found the way the ASP.NET sever controls get rendered is not exactly how you want or need it, then MVC is a better choice as it will allow you to have control over the final rendering. If you do not have any main issues with how ASP.NET web form server controls get rendered in your applications, then this might not be an "advantage" that you can sell to your tech manager or team when trying to build the next project using MVC.

Another advantage of using ASP.NET MVC that ties back into the individual layers is testability, specifically unit testing. Because the application is loosely coupled with code in its separate layers, the ability to create unit tests increases greatly. The event based ASP.NET pages that rely on things like Session, Context, Response, etc are quite difficult to effectively test because of the inability to isolate specific page functionality due to its nature of being spread out and external dependencies as well. MVC improves on this greatly, and is architected to be testable. 'Point' MVC.

So let's examine ASP.NET web forms for a minute. As I mentioned they were born sometime in late 2001, so maturity and a rich tool set (both from Microsoft and 3rd party) is a big advantage. These "tools", or ASP.NET server controls make up a style of development referred to often when speaking of ASP.NET web forms called RAD or Rapid Application Development. "Hey I can drag a few ASP.NET text boxes, some labels, this Gridview thingy, press publish, and WHAT??!! I have a website!" Now that website might be junk, but hey its done already. On to the next project, right? Well not quite. 'Fast', especially in our field doesn't mean better. That site might be done, but as eluded to prior, its design is junk and it will not maintain or scale well. But what if you know the scope is a single, simple page? Well then a tool like web forms is probably perfect, and MVC might be overkill if speed of development is of the essence. Don't be fooled, web forms + data binding, etc. will be faster to generate just based on the drag-and-drop + wizardry capabilities. Just don't have a code review and everything will be fine! So the RAD capabilities of ASP.NET web forms can be a double edged sword. A quality ASP.NET web forms with a pre-determined architecture (3-layer, Domain Driven Design, MVP, etc.) that uses developers with discipline to adhere to it, is a much better choice when creating ASP.NET web form applications.

Along these lines is another advantage with web forms and that is 'Experience'; specifically in relation to a developer's experience with the technology. Again with web forms being a mature technology going on 10 years, there is a solid developer core with ample experience. If you are leading a team of 8-10 developers, you are the only one with MVC experience, and everyone else knows web forms, then this needs to play into your decision of which technology to use. Are you prepared to take the financial impact of formal MVC training through remote seminars, current books, or on-sight training? Can you afford the 1-3 month setback while the team gets up to speed on ASP.NET MVC to say a beginner/intermediate level? If these are not an issue, and the advantages of ASP.NET MVC mentioned previously are present, then it may be the better choice regardless of the upfront cost in time, money, etc. If however, you need to begin writing code immediately with a team of web form rich experience developers and are under a tight deadline, then maybe holding off on using MVC is the better decision. In the end you need to weigh the factors to make the best decision.

There are some other disadvantages to the web forms technology that I will mention briefly here as well. The web form's postback model uses client side generated '_doPostBack()' events for each server callback. If JavaScript is disabled this will cause several problems for the web forms application. It is also difficult to manipulate manually if writing your own client side scripts. MVC improves on this using REST based URLs. The next disadvantage with web forms is ViewState. Referring back to my comments about poorly designed web form applications, a bloated ViewState can cause pages to be larger and slower than they need to be. ViewState stores a base64 encoded string with information about controls state to persist postbacks and to help combat the stateless nature of the web. This however becomes a disadvantage for web forms when abused.

Now let's throw a cog into the wheel and add in another choice for web development in the .NET realm: Silverlight. Oh yeah, and honestly my favorite when it comes to rich UI content. However, you still need a hosting application and Silverlight can be integrated into either ASP.NET web forms or ASP.NET MVC applications. And I don't want to confuse anyone either because Silverlight is not an entire 'web' Framework onto its own and only works alone as individual controls. The Silverlight controls integrate into a web forms or MVC application as just another control and can co-exist with controls of either technology. However, since Silverlight can't invoke the controller class in MVC, or directly postback to the server when using web forms, you will need to use services (WCF) to accomplish this task. Anyone using Silverlight previously knows that WCF services can bridge the gap between the Silverlight control and the server.

Decisions, decisions, which technology to pick? There is a lot to weigh when it comes to these two technologies: ASP.NET web forms or ASP.NET MVC. Are you trying to draw a line in the sand and say, "Only MVC web apps from here on out!!" Personally I would not do that, because it wasn't like 10 years ago when we moved from classic ASP to ASP.NET and were able to be that bold. Now ASP.NET MVC has to be looked at as another tool (a very powerful and cool one) in the proverbial toolbox. There will be a time when MVC is the proper decision, and a time when web forms is the proper one. I strongly urge those picking web forms to at a minimum not fall into the trap of bad or poorly architected code, and be disciplined to use an architecture that is more scalable and maintainable (check my review of the book Professional ASP.NET Design Patterns). And lastly and maybe most importantly, be a 'realist' and not a 'purist' when making this decision. Do what is best and right, and not just which one theoretically is better in argument. This will help you decide. Either way its great to be a .NET developer with such a plethora of technologies to choose from.

How to Serialize a SyndicationFeed Object To Be Returned From WCF

Recently I have been working with the SyndicationFeed class in the System.ServiceModel.Syndication namespace. It allows us as developers to work nicely with Atom 1.0 and RSS 2.0 content. A problem arose when I needed to return this object from RSS to a consuming Silverlight client. The problem was that the raw SyndicationFeed class is not serializable, so I needed a solution to serialize the Feed and return it.

This was one time I was happy to find that no custom serialization methods, or mimicking all property values in my own DataContract to return was going to have to be the solution. Instead there are 2 nice classes in the same namespace that do exactly this for us: the Atom10FeedFormatter & Rss20FeedFormatter classes.

In my case I was working with Atom 1.0 content so I was able to use that Serialization class. The solution was simple. Alter my WCF service to return a type of 'Atom10FeedFormatter' defined both on the OperationContract and implementing service method. Then the client can define the return type to receive, and place it right back into a SyndicationFeed object if desired. There are also Atom10FeedFormatter(Of TSyndicationFeed) & Rss20FeedFormatter(Of TSyndicationFeed) classes to serialize classes that derive from those types, and there are all the same classes for the 'SyndicationItem' object as well. Needless to say there is some flexibility in serializing this data to be returned.

So let’s take a look at the code; 1st the code to extract a SyndicationFeed (i.e. from an RSS link off the web).

'Make a call to extract RSS information from the web
Dim proxy As New WebClient()
'Load stream into a reader
xmlRdr = XmlReader.Create(proxy.OpenRead(New Uri("http://rss.cnn.com/rss/cnn_topstories.rss")))

'Load syndicated feed (Atom)
Dim feed As SyndicationFeed = SyndicationFeed.Load(xmlRdr)

Next the code to Return from the method the Atom10FeedFormatter. I do this inline in the Return statement as it is easiest:

Return New Atom10FeedFormatter(feed)

Lastly, the client code to receive the Atom10FeedFormatter and place it back into a SyndicationFeed object. You may wish to do this before binding to controls.

Dim wcfSrv As New MyWCFService.MyWCFServiceClient
'Create the Formatter which will be returned from the RSS call below
Dim MyRssSyndicationData As Atom10FeedFormatter
MyRssSyndicationData = wcfSrv.RssFeedData()

'Load the returned formatter back into a SyndicationFeed object if desired
Dim RssDataFeed As SyndicationFeed = MyRssSyndicationData.Feed

So that's it! If you want to learn more about these classes that make serializing SyndicationItem or SyndicationFeed classes so easy, take a look to the following link:

System.ServiceModel.Syndication Namespace

Setting Up the ClientBin Folder to Debug a Silverlight Control in a Test ASP.NET Application

If you create a new Silverlight control using either VS.NET 2010 or Expression Blend 4, you are already off on the right foot for setting up a test ASP.NET application for running and debugging a Silverlight control. The newer versions of these applications configure well the test project, creating the 'ClientBin' folder, and associated test .aspx page including preconfigured <object> tags referencing the control.

But what if you have an old or mis-configured project that manually references a .xap file, or had to be constantly updated in Explorer in the referenced path? It is especially important to have the configuration correct in a test app or debugging the .xap from the source Silverlight project is not possible. The following steps describe how to easily reconfigure your ASP.NET test harness to properly reference the .xap generated from the Silverlight control created within the same solution.

1. Right click the ASP.NET test project and select 'New Folder'. Name it 'ClientBin' (without the quotes). Only do this step if the folder does not already exist.

2. Right click the ASP.NET test project (this project should be in the same solution as the Silverlight Control being referenced) and select 'Properties' (or 'Property Pages' for website projects).

3. While still in the Properties, open the 'Web' (for web project types) or 'Start Options' (for website types) and make sure to scroll down and have the 'Silverlight' checkbox checked under 'Debuggers'.

4. Select the 'Silverlight Applications' tab or selection on the left hand pane.

5. Click the 'Add' button to bring up the 'Add Silverlight Application' dialog box.

6. Make sure the radio button selection for 'Use an existing Silverlight project in the solution' is selected, and select the Silverlight control to reference.

7. In the 'Destination folder:' field, make sure 'ClientBin' is in the textbox. This will most likely be pre-populated.

8. Configure the remaining options to your liking. I suggest leaving 'Add a test page that references the control' checked as this will save you from having to do this from scratch.

At this point try starting debugging the Silverlight code by placing a breakpoint in the source. Obviously make sure the ASP.NET test app is set as the default project, and set the newly created page to be the startup page. If you configured it correctly, your code will properly place any new builds of the .xap into the ClientBin folder of the test app, and should allow for proper debugging.

Fixing the "attempting to access a service in a cross-domain way..." error when consuming a WCF service running via a VS.NET 'localhost' binding

There must be 1000 good blog posts about setting up the clientaccesspolicy.xml and crossdomain.xml files for a WCF service being accessed by a Silverlight application or control. This consists of dropping these files in the root of the site on the server where the site is hosted. But where do these guys go if you are actively running your WCF service locally (through VS.NET) and still want to consume the service?

I recently had my WCF service running through VS.NET so I could consume and debug it through an ASP.NET test harness. This is a really powerful way to iron out any WCF service issues. Upon launching the .aspx page that contained the .xap Silverlight control that had consumed the localhost version of the WCF service running (not a locally installed WCF service to reiterate; just actively running through VS.NET) I began to get the following exception:

"An error occurred while trying to make a request to URI 'http://localhost:6000/MyWCFService.svc'. This could be due to attempting to access a service in a cross-domain way without a proper cross-domain policy in place, or a policy that is unsuitable for SOAP services. You may need to contact the owner of the service to publish a cross-domain policy file and to ensure it allows SOAP-related HTTP headers to be sent."

What - I thought I fixed this a long time ago?? I realized I had never configured the clientaccesspolicy and crossdomain .xml files just for a service running locally. I started plopping those (2) files everywhere: wwwroot, project, etc. I finally found where they should be placed in order for an ASP.NET app containing a Silverlight control that has consumed a locally running WCF service is supposed to go: in the root of the project folder alongside the .svc and .vbproj files. Once I placed the (2) files into that directory containing the raw VS.NET files, the SL control began working properly.

Makes 100% sense too. If running through VS.NET Cassini local server, those files should be located with the actual service itself.

Again, this is only 1 of many, many ways to solve the original issue at hand. This is only a solution for Silverlight controls that consume a locally running (not installed) WCF service. Hopefully this saves someone else a few minutes.

Dealing With the Removal of the ASP.NET Silverlight Server Controls in Silverlight 3

Silverlight 3 has been out for some time now, and most Microsoft sites you may visit often (including Microsoft Update) will prompt you to do the install. If you did the install and removed all of Silverlight 2 including the SDK as required to run the full Silverlight 3 SDK, then you may have notices a few things break in your existing Silverlight 2 applications or controls.

This is because with the advent of Silverlight 3, the convienient ASP.NET Silverlight server controls were removed. The solution is to use the more generic <object> tag to reference controls and pass parameters. While I understand the premise behind this and have seen quite a lot of documentation, I have not see a lot of thorough examples on a 1:1 conversion. In fact in some instances I read where the <asp:mediaplayer> tag was used, that the .js encapsulated behind that would now have to be incorporated into your control. The suggestion was to use Blend with Encoder to make this easier by using one of their templates, and then exporting a .xap file.

I think the easier conversion will be for those that used just the <asp:silverlight> tag to reference a .xap control. In this case you could probably easily convert the code to using the <object> tag and pass in any needed parameters. However, I think converting the <asp:mediaplayer> references are going to involve more work.

If you are looking for the fastest solution to fix your current application so that it will work, to buy time to make the full conversions to SL3 (or maybe wait until SL4 is RTM, because my experience is each SL release has had major changes that don't upgrade so well; that's ok though - the growing pains come with the territory of new technology) then here it is. You need to go to the /bin of a currently deployed solution and try to find the following .dll: System.Web.Silverlight This .dll has the asp.net Silverlight Server controls. If you copy that .dll into a 'Components' directory of sorts (or into the /bin, however your process dictates) and add a reference to that .dll, your errors should go away. If you do not have a copy of the .dll anymore, you can download the Silverlight 2 SDK and get the .dll from there as well.

For a more detailed reference on ensuring your Silverlight 2 application work with Silverlight 3, check out the following link:
Ensuring That Your Silverlight 2 Applications Work with Silverlight 3

For a more detailed reference on persisting the Silverlight 2 ASP.NET server controls, take a look to the following whitepaper:
ASP.NET Server Controls for Silverlight in the Silverlight 3 SDK

One of the better references I have seen for parameters that can be passed to an <objectgt; tag:
Silverlight 3 object tag param list