This is a bug not in SP1 itself, but shared in several other hotfixes released after SP1.  Some notable culprits are KB971092, KB972222, and KB973675, all of which show up on Microsoft update.  There is a setup authoring bug in these patches which prevents the user from changing the set of installed features. 

This setup authoring bug has been fixed and can be installed via later hotfixes.  One of these is KB979576, which can be found at https://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=27638.  This hotfix is for an unrelated issue, but also contains the setup authoring fix. 

The alternative to installing the additional KB is to uninstall any other KBs which may have the bug (not including SP1/KB945140, since it’s clean); however, this is several hundreds of MB of patches, whereas the above patch is just under 7MB.

The workaround for this is to install the latest Silverlight developer runtime, which you can find at https://go.microsoft.com/fwlink/?LinkID=188039

Sorry for the inconvenience; we’ll review this design decision for SL 5 and determine how to improve the experience.

We’ve had a number of users comment that the couldn’t find the file.  This is because the file is only written when you run Visual Studio’s executable (devenv.exe) with the /log parameter.  If you are reporting an issue to us (especially through the Connect site), the contents of the log file are very useful.  If you’re developing a custom extension to Visual Studio, this can also be useful for determining when and why something doesn’t work.

There are two easy ways to run Visual Studio with the /log parameter.  First, from the command line:

And second by editing the shortcut you use to run it:

After checking the immediately obvious (i.e. is the SDK installed), you might wonder why this is happening.  It has to do with the build running under 64-bit MSBuild.  The Silverlight build tasks determine which versions of the framework are installed by reading from the registry.  This key in 32-bit Windows is under HKLM\Software\Microsoft\….  On a 64-bit system, however, it’s under HKLM\Software\Wow6432Node\Microsoft\…, and the build tasks fail to find the values they’re looking for.

To work around this issue, you need to set your project to build under the x86 toolset.  To do that in TFS, you need to edit your build configuration to build for the x86 platform:

We do not have a fix for this at this time, but we are tracking the issue for an upcoming release.

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.

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:

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!

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 https://go2.microsoft.com/fwlink/?LinkID=157102. 

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

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.

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!