So imagine you’ve created this awesome Silverlight application. The app works great and everyone’s happy. In this particular case the client was using an automated build tool called Anthill which is how they deploy their CRM solutions. The later versions of the CRM SDK have a deploy function where you can have your code in TFS and deploy your plugins and web resources straight from your project after pointing the Visual Studio CRM Explorer add-in to a specified server and organization. This all sounds great until I get a call saying that my wonderful Silverlight application isn’t working.

Distraught and aggravated I start contemplating would could have possible gone wrong. What could I have possibly done wrong? As it turns out when I go to the deployment server the Silverlight control decided to not show up in a matter of speaking. Just to give some background this is a Silverlight control hosted in an HTML web resource displayed in the form content iFrame from a navigation link. The page shows up just fine, but my control isn’t loading. Weird…

CRM stores web resources in its SQL Server database. When you create an HTML web resource it changes the Silverlight object tag and encodes the parameter information so it isn’t the same as what you may have uploaded. After a conversation with a Microsoft engineer I became concerned thinking that either the XAP file could be corrupted in the database or the encoding was somehow was messed up in my object tag. At first I couldn’t see anything wrong. Everything appeared to be in order.

The following is the process I underwent to discover the problem:

  • Checked to see if the Silverlight control was functioning correctly:
    1. Placed the Silverlight control directly on the form.
    2. Opened the Silverlight control directly from the web resource dialog.
  • Check to see if the host web page was displaying correctly:
    1. Updated the HTML to view changes were updating in iFrame.
    2. Debugged the Silverlight object tag to ensure that the parameters were still set correctly and they appeared to be good.
    3. Overwrote the HTML with a known working copy to check if something was corrupted.
    4. Used Fiddler to see if anything stood out watching IE’s server calls.
  • Check to see if I could reproduce the problem on another system:
    1. Imported the solution to my test VM and everything worked fine.
    2. Created new test org on my VM and used the Visual Studio deploy operation and BOOM! Nadda.

As it turns out when I used the deploy function my control would never display on the host page. This was particularly perplexing because it was a difficult to determine the problem. I recalled one of my coworkers stating a problem he had using the deploy mechanism to reload an existing org. He mentioned that another developer had manually unregistered and reregistered a plugin assembly and that he couldn’t use the deploy process anymore because it was complaining that the guid’s were not the same. In TFS we keep a copy of the org customizations that we import separately before we use the deploy function. When I looked in this solution I couldn’t find my host web page or my Silverlight control although the deploy process was creating them on it’s own. I added my host web page and Silverlight control to that solution and everything started working.

Don’t take this to the bank but, here is my observation and conclusion. The host HTML page and Silverlight control were not in the solution that was being imported into the target organization. The deployment process would take what it saw needed to be on the server and deploy them as new web resources. I believe the problem has something to do with the Silverlight XAP file being stored in the database with a specified id. The encoded HTML page was pointing at that particular Id, but the Id changed because the XAP file was not part of the solution. After adding the necessary files the Id’s remained the same thereby keeping the pointers correct when the solution was deployed using the SDK tool.

I know this is probably a unique problem and is less likely to happen, but this is what I discovered to correct the problem I was having with my Silverlight app. Now I have regained my former glory as master of Silverlight.