Jimmy Lewis' blog

If you have a Silverlight application that is consumed by a Web Site Project in Visual Studio (not to be confused with a Web Application Project), and you use msbuild on your solution, you may find that the XAP file is not copied to the website.  This will also happen if your solution is building via Team Foundation Server’s Team Build, or another similar tool. 

The issue is that since Web Site Projects (WSPs) do not have a project file associated, they are dumb about copying the XAP file.  When you build from Visual Studio, we wrap some extra smarts into the process to make sure it happens correctly.

You can work around this by creating an AfterBuild command for the Silverlight project to copy the XAP file to the WSP (normally the web project consumes the Silverlight output on its own).  This can be done by editing the project file for the Silverlight app.  The project file contains the following section towards the bottom:

<!-- To modify your build process, add your task inside one of the targets below and uncomment it. 

     Other similar extension points exist, see Microsoft.Common.targets.

<Target Name="BeforeBuild">

</Target>

<Target Name="AfterBuild">

</Target>

-->

You can hook the AfterBuild target to do the work of copying the XAP file, like this:

<Target Name="AfterBuild">

    <Copy Condition="" SourceFiles="bin\Debug\SampleSilverlight.xap" DestinationFolder="..\SampleSilverlight.Web\ClientBin" />

</Target>

SourceFiles should point at the XAP file, and DestinationFolder should be a path to the WSP.  Since the Silverlight app will build before the WSP, you don’t need to worry about lining it up right with the PrecompiledWeb folder – the WSP compilation will copy the XAP for you.

One scenario that happens fairly often for new apps is to create a new project and then part way through decide you want to rename it, or at least the default namespace.  With Silverlight apps, when you do this and try to run your project, you’ll see an error:

Line: 56
Error: Unhandled Error in Silverlight Application 
Code: 2103    
Category: InitializeError       
Message: Invalid or malformed application: Check manifest     

This happens because the EntryPointType in the AppManifest.xaml file is not updated when the refactoring occurs.  This value is generated at build time from the Startup Object in the project properties.  You can fix this issue by updating the Startup Object for your project:

This evening I put up a blog post on my team’s blog to summarize some of the changes that have come in the Beta 2 release of VS2010 with regards to Silverlight development.  Check it out and leave any feedback.

If you’re trying out the new beta, please give feedback and tell us what you think.  While we can’t address everything for the final VS2010 release, we do make customer bugs and suggestions a priority.  You can file bugs or new suggestions on the Microsoft Connect website, under the Visual Studio and .NET Framework connection.  Also, feel free to post on the MSDN forums for VS2010 Beta 2, the ASP.NET forum for Beta 2, or on the Silverlight forum for Visual Studio.

Hope you’re enjoying the new release!

Some folks have already started trying out the latest VS2010 release, and have been receiving installation failures for the Silverlight 3 SDK.  This is a known issue, and fairly easy to work around.

The problem is caused by having the Silverlight 3 RTW version of the SDK installed (3.0.40624.0).  VS2010 tries to install the Silverlight 3 GDR2 version (3.0.40818.0), which doesn’t automatically upgrade in place.  The GDR version fails to install, giving this error.

This does not completely break Silverlight development scenarios, as some people are already reporting.  However, there may be some minor issues that come up if you’re using the Silverlight 3 RTW SDK.  To fix this issue, you can uninstall the Silverlight 3 SDK, and install the latest version from http://go2.microsoft.com/fwlink/?LinkID=157102. 

We are working on providing a smooth experience for the VS2010 RTM release.

On an internal mailing list yesterday, someone asked how to debug their Silverlight 3 application as it runs Out of Browser.  They were seeing some behavior that would only reproduce in the first few seconds and only in OOB mode.  Fortunately, you can install your app locally and then debug it directly in the Out of Browser window.

In the Silverlight project properties, on the debug tab, you can enable launching it as an OOB application:

The drop down box contains all of the web projects in the solution which consume your Silverlight application.  Because they are treated as different installs by the runtime, you may want to change this setting if issues occur when installing from one web project but not another.  The notice below the dropdown simply indicates that you haven’t installed the Silverlight application in the context of that web project yet.  If the notice does not appear, then you’re good to go.

The next step after enabling OOB debugging is to set your Silverlight app to the startup project.  Normally the web project is the startup project, and it hosts the Silverlight app; in this case, we don’t want to run the website.  To set the startup project, just right-click the project in Solution Explorer and select ‘Set as Startup Project’. 

You’ll know which project is set as it will be in bold in Solution Explorer.

Now when you start debugging, the application will launch in Out of Browser mode.  To go back to debugging in the web site’s context, simply change the web project back to being the startup project.

With the release to web (RTW) of Silverlight 3, a lot of folks will [hopefully] be upgrading to take advantage of the new features now offered.  The first question that will come up probably is, “how do I upgrade?”  Upgrading should actually be a very easy experience.  The Silverlight 3 Tools installer will do most of the work for you:

1. Update your developer runtime to the latest version (Silverlight 3 RTW, or newer if Silverlight is ever patched)
2. Install the Silverlight 3 SDK
3. Uninstall Silverlight 2 Tools for VS2008
4. Install Silverlight 3 Tools for VS2008
5. Install a new patch to VS2008 for Silverlight

Note that it will not uninstall the Silverlight 2 SDK.  It is perfectly fine to have these both installed together; you may even desire this if you wish to continue using the ASP.NET controls for hosting Silverlight in your web page (note: the ASP.NET controls probably will not work correctly if you’re taking advantage of the new browser navigation features).

You will need to update your installed version of the Silverlight 3 Toolkit Controls manually.  Since this is not part of the basic set of tools for Silverlight development in VS, we don’t manage the upgrade for it.

Hope this clears up any confusion!

There’s been some confusion with setting up Silverlight development the VS 2010 Beta 1 release, since the Silverlight SDK and developer runtime are part of the installation.  In order for Silverlight to work in VS2010, you need to install both the SDK and developer runtime, but there is not a separate package for the Silverlight Tools itself.  This will be fixed in the next beta of VS2010.

For now, if you want to install these packages, here’s some links:

Note that there are some issues when using Dev10 Beta 1 with Silverlight 3 RTW, but most of these can be worked around.  We’ll have more info on that soon.

In Dev10 Beta 1, which was just released, there isn’t any way to enable the Transparent Platform Extensions (aka Assembly Caching) or Out of Browser features for Silverlight 3 Beta.  To enable these manually is pretty straight forward.  However, you should note that they are currently incompatible with each other; you can use one or the other, but not both in the same Silverlight application.

To enable TPE, you need to edit the project file and add a new property:

1. Right-click the project in the Solution Explorer window and select Unload project.
2. Right-click it again and select Edit <yourprojectname>.proj
3. Under the first <PropertyGroup> add the following:

<UsePlatformExtensions>true</UsePlatformExtensions>

Now, right-click the project again and choose Reload Project.  Save the changes if prompted.

Enabling the Out of Browser feature is the same as in the Silverlight 3 Beta Tools for VS2008 SP1.  You need to paste a chunk into the AppManifest.xml file used as a template when generating the AppManifest.xaml file.  The file is located under the Properties node in Visual Studio:

To enable the OOB settings, paste the following snippet into the file (usually after the <Deployment.Parts> node):

<Deployment.ApplicationIdentity>

    <ApplicationIdentity 

        ShortName="Your Out of Browser Silverlight Application" 

        Title="Window Title of Your Silverlight Application">

        <ApplicationIdentity.Blurb>Description of your Silverlight application</ApplicationIdentity.Blurb>

    </ApplicationIdentity>

</Deployment.ApplicationIdentity>

In Dev10 Beta 1, the Silverlight-enabled WCF Service template is the version used for Silverlight 3 beta.  This uses a custom binding to enable binary encoding, and is incompatible with Silverlight 2 applications.  If you attempt to add a reference to it, you’ll see errors like the following:

(note that you might also see this error if you are using Silverlight 3 beta and have the Silverlight 2 SDK installed)

To make it work with Silverlight 2, however, you can just tweak to the web.config where the service is hosted to use basicHttpBinding without the custom bindingConfiguration.  In the web.config file, under the <system.serviceModel> node change the configuration from something like:

<services>

    <service behaviorConfiguration="UseSilverlightWcfTemplate.Web.Service1Behavior"

        name="UseSilverlightWcfTemplate.Web.Service1">

        <endpoint address="" binding="customBinding" bindingConfiguration="UseSilverlightWcfTemplate.Web.Service1.customBinding0"

            contract="UseSilverlightWcfTemplate.Web.Service1" />

        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />

    </service>

</services>

to:

<services>

    <service behaviorConfiguration="UseSilverlightWcfTemplate.Web.Service1Behavior"

        name="UseSilverlightWcfTemplate.Web.Service1">

        <endpoint address="" binding="basicHttpBinding" contract="UseSilverlightWcfTemplate.Web.Service1" />

        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />

    </service>

</services>

Then rebuild the web project and update your service reference.

With the release of the Web Platform Installer 2.0 beta at MIX last week, you can now install any of the cool development packages we’ve been releasing with a single combined application.  However, there are a couple issues that can come up, especially around the Silverlight Tools packages. 

If your Silverlight Tools package fails to install, WebPI unfortunately doesn’t give you a very useful message.  You’ll probably see something in the log file that looks like:

DownloadManager Information: 0 : Adding product Silverlight 3 Tools for Visual Studio Beta (www.microsoft.com/web/webpi/2.0/WebProductList.xml?121) to cart
DownloadManager Information: 0 : Product 'www.microsoft.com/web/webpi/2.0/WebProductList.xml?121' was already in cart.
DownloadManager Information: 0 : No SQL to configure
DownloadManager Information: 0 : Setting current install to 1
DownloadManager Information: 0 : Starting install sequence
DownloadManager Information: 0 : downloading file 'http://go.microsoft.com/fwlink/?LinkId=146358' to: D:\Foo\Silverlight3_Tools.exe
DownloadManager Information: 0 : Starting EXE install for product 'Silverlight 3 Tools for Visual Studio Beta'. Commandline is: 'D:\Foo\Silverlight3_Tools.exe /q'
DownloadManager Information: 0 : Waiting for process: 220 - D:\Foo\Silverlight3_Tools.exe
DownloadManager Information: 0 : Install exit code for product 'Silverlight 3 Tools for Visual Studio Beta' is 1
DownloadManager Error: 0 : Install return code for product 'Silverlight 3 Tools for Visual Studio Beta' is Failure
DownloadManager Information: 0 : Product Silverlight 3 Tools for Visual Studio Beta done install completed

This really only tells you that the installation failed.  For some possibilities as to the problem, see Amy Dullard’s blog post about Silverlight Tools Installation Error Codes.

If your problem is not listed, you’ll need to look at the Silverlight Tools installation log, which is located under your temp directory.  The file name will look something like: Silverlight 3.0 Tools Beta 1_<date>_<timestamp>.html.  If you open this and then scroll to the bottom, it should give some information about the error.

If you can’t figure out the problem from the Silverlight Tools installer log, leave a comment and I’ll help you resolve the issue.

With the release of Silverlight 3 Beta, you’ll may want to try out the new features.  Unfortunately, Silverlight 3 Beta is a developer only release (no end-user runtime, no GoLive license), so you might end up going back and forth.  Even more unfortunate is that Visual Studio 2008 doesn’t have much room to create a multi-targeting environment for developers, so you’ll have to switch between which packages are installed.

To upgrade from Silverlight 2 to Silverlight 3, simply run the new installer (found here).  It will automatically remove the Silverlight 2 Tools for VS package, which is incompatible with the Silverlight 3 package, and then install the new packages you’ll need for Silverlight 3 development.  (Note: If you’re looking to take advantage of the binary encoding for WCF services now available in Silverlight 3, you’ll have to remove the Silverlight 2 SDK manually; see here for more info.)

To downgrade from Silverlight 3 to Silverlight 2, there’s a couple extra steps required.  The Silverlight 2 installer doesn’t know to check for the Silverlight 3 packages, so you’ll have to remove them by hand.  This can be done through the Add/Remove Programs applet in the Control Panel.  The packages which need to be removed are:

1. Microsoft Silverlight 3 Tools for Visual Studio/Visual Web Developer (this needs to be removed because the Silverlight Tools packages are incompatible; if both are installed, VS/VWD will use the Silverlight 3 version)
2. Microsoft Silverlight (the version 3 runtime causes the Silverlight 2 Tools installer to fail; we’re working on a solution)

After that, run the Silverlight 2 Tools installer again (found here).

To make this easier, Amy Dullard (one of our team members) has put together some scripts to automate this process.  See her blog post here for more info.

In Silverlight 3, the help files are shipping as a separate CHM file, instead of integrating with the offline Visual Studio documentation.  We received a lot of feedback during Silverlight 2 about the installation time being very long, and one of the main culprits was merging the help files.  If you want to keep a copy of the help files locally (i.e. you don’t want to use online help), you can download the offline CHM here.

In Silverlight 3, we’ve introduced support for binary message encoding for WCF services, which should give a performance boost.  Silverlight 2, as you may recall, only supports basicHttpBinding.  The new binding is the default for Silverlight-enabled WCF services created with the Silverlight 3 Tools.

If you’ve upgraded from the Silverlight 2 Tools for Visual Studio to the Silverlight 3 Tools for Visual Studio, you may run into the following warnings when adding a reference to a newly created WCF service (i.e. using the new template in Silverlight 3 Tools):

If you continue to run your Silverlight application, it will throw an exception when you try to instantiate a client for your service.  The stack trace will look like the following:

The given key was not present in the dictionary.

   at System.ThrowHelper.ThrowKeyNotFoundException()
   at System.Collections.Generic.Dictionary`2.get_Item(TKey key)
   at System.ServiceModel.Configuration.ServiceModelSectionGroup.get_Client()
   at System.ServiceModel.Description.ConfigLoader.LookupChannel(String configurationName, String contractName, Boolean wildcard)
   at System.ServiceModel.Description.ConfigLoader.LoadChannelBehaviors(ServiceEndpoint serviceEndpoint, String configurationName)
   at System.ServiceModel.ChannelFactory.ApplyConfiguration(String configurationName)
   at System.ServiceModel.ChannelFactory.InitializeEndpoint(String configurationName, EndpointAddress address)
   at System.ServiceModel.ChannelFactory`1..ctor(String endpointConfigurationName, EndpointAddress remoteAddress)
   at System.ServiceModel.ChannelFactory`1..ctor(String endpointConfigurationName)
   at System.ServiceModel.EndpointTrait`1.CreateSimplexFactory()
   at System.ServiceModel.EndpointTrait`1.CreateChannelFactory()
   at System.ServiceModel.ClientBase`1.CreateChannelFactoryRef(EndpointTrait`1 endpointTrait)
   at System.ServiceModel.ClientBase`1.InitializeChannelFactoryRef()
   at System.ServiceModel.ClientBase`1..ctor()
   at Somewhere.In.Your.Silverlight.Application()

This is caused by a bug where the Microsoft.Silverlight.ServiceReference.dll assembly is loaded into VS from the Silverlight 2 SDK instead of the Silverlight 3 SDK.  Since Silverlight 3 adds support for binary encoding in WCF services, when you add a service reference to such a service using the Silverlight 2 assembly it fails and the generated ServiceReferences.ClientConfig is non-functional.

To work around this issue for now, uninstall the Silverlight 2 SDK, update your service reference, and rebuild your Silverlight application.

If you want your service to be consumable by both Silverlight 2 and Silverlight 3 applications, you can change the binding back to basicHttpBinding.  To do that, edit the web.config file for the web project containing the service.  Then update the service reference and rebuild your Silverlight application.

A fair number of people are having issues with the ASP.NET control used to host Silverlight applications ceasing to work when they upgrade from Silverlight Beta 2 to Silverlight 2 RTW.  If the HTML page is also broken, the first thing to check is that the HTML markup is correct, since the MIME types have changed between the two releases.  In RTW, the HTML <object> snippet now looks like this:

<object data="data:application/x-silverlight-2," type="application/x-silverlight-2" width="100%" height="100%">

Note that both the data type and the application type have end with -2.  The reason for changing the data type was to resolve an issue on Firefox.  That scenario was that Firefox with Silverlight 1 (but not Silverlight 2) would try to run the application with the wrong plug-in; it was not an obvious issue when debugging, so do double check both types.

If the HTML page is still not working, then it's possible that the Silverlight application is broken.  Review the breaking changes (or see Mike Snow's post on it here) to make sure that your code is correct.

Once the HTML page is working, if the ASPX page is still not working, the issue is most likely caused because the System.Web.Silverlight.dll on the server is out of date.  The assembly from Beta 2 would output the incorrect MIME types; if you purge it from the server and replace it with the version in the RTW SDK (2.0.30825.0), it should begin to work correctly.

The RTW release of Silverlight Tools for VS 2008 is out!  There are no functional changes from RC1, and hence no upgrade prompts or breaking changes.  The hot-fix was re-built for servicing reasons, so please do upgrade.  If you are upgrading from RC1, you should see the following packages being updated:

The non-English releases are still being translated; since there are no functional changes between RC1 and RTW, there should be no issues with continuing to use those RC1 releases.  We will release the localized RTW as soon as we have the translations done.