Silverlight Application Deployment

Silverlight Application Deployment

Silverlight Application Deployment 1 Steps to Deploy Silverlight Business Application Many people have trouble deploying Silverlight Business Applications to IIS. They tested everything under Visual Studio. But once they deploy the app to IIS, the app stops working. Either Silverlight can't connect to the service any more, or there are database connection related errors. If you have trouble deploying your Silverlight Business Applications, check this general RIA deployment guide first: http://blogs.msdn.com/b/bradsevertson/archive/2011/02/17/a‐guide‐to‐deployi ng‐ria‐services‐ solutions.aspx If you are still having trouble, let's do this step by step to deploy a Silverlight application created by using the Silverlight Business Application Template: 1) Create a Silverlight Business Application in Visual Studio (VS).

Run your app by hitting F5 under VS. The application's main page is loaded in your default browser. Click the Login button. First you need to Register a user: Click "Register Now" button on the Login window; enter your user information to register. After you are done the login window is closed and you should already be logged in. Click Logout button to Logout. Click Login Button to login again. If everything works at this point, we can consider we already tested every feature of this application and ready to deploy it.

You may wonder how everything just works by itself and you haven't even written any code yet. Where is the user data stored at? Those things are done by the code generated by VS. When VS create this project, there is a SQL server database file ASPNETDB.mdf created under the App_Data folder in the Web Project. This DB file holds application user membership data used by the authentication service. The connection to this DB is defined under the Web.Config section. It looks something like this: If you are using earlier version of the RIA service (earlier than RIA service SP1 beta), you may not see the connection string under the Web.Config.

If this is the case, the default connection string used by

Silverlight Application Deployment 2 ASP.NET authentication service is defined in the machine.config. You can check your machine.config under x:\\Microsoft.NET\Framework\\config\machine.config. You should see the following connection string defined in machine.config: If you are on earlier version of RIA and do not see connection string in your Web.Config, first thing you should do is to add one to override the connection string set in machine.config. Add the following to your Web.config file: When you are under development, the project is using SQL Express to access the DB file. Remember SQL Express is for development only.

When you finally deploy your app, you should use a full version SQL server in your production. But for testing purposes, you can still use SQL Express to test your deployment.

2) Change the connection string to use SQL server authentication in the Web.Config: The default connection string uses Windows authentication. It works under the DEV server when you are running the app under VS because the thread is running under the current windows user account. But when you are running the app under IIS, the thread is running under "NT AUTHORITY\NETWORK SERVICE" user account. This user account does not have the right to access the SQL server unless you give it that right. The best practice for a Web application is to use SQL server authentication. If this is your original connection string:

Silverlight Application Deployment 3 Change it to the following: If this is your original connection string: Change it to the following: 3) Include ASPNETDB file in the deployment package. If you want to deploy the ASPNETDB.mdf file with your solution, you need to include this file into your Web Project. Click Project Menu on the VS Top Menu bar, select "Show All files". You should now see the ASPNETDB.mdf file under the App_Data folder under the Web project. It is not included in the Project by default. Right click the file and select "Include in Project".

Any files you want to include in the deployment package, you need to include them into the project.

Otherwise, the folder or files won't be published. 4) Build your solution. Do a final test of your app under VS.

Silverlight Application Deployment 4 4) Publish your app to a local file folder If everything works at this point, you can publish the solution using the publish feature under VS. Right click your Web project to select "Publish . Select File System as your publish target. Select a local file folder to publish the package. 5) Test your deployment on your local IIS. This is a important step. Before you finally publish the application to the hosting server, test it on your local IIS first, so you still have a chance to debug the problems if you find any. Open the IIS Admin tool (under Computer\Manage\Service and Applications) on your local computer.

Add an Application under Default Web Site to point to the published folder you just created. Make sure that you select ASP.NET v4.0 as the application pool.

Under IIS Admin, right click the web application, go to Authentication Details, make sure only the Anonymous authentication and Forms authentication are enabled. 6) Test your App by enter "http://localhost/YourApplication/YourTestPage.html" in a browser. If you find problem running under local IIS, you can use "Attach to process " VS feature under the Debug menu to debug your code. For server side code debugging, attach to "w3wp.exe". For Silverlight code debugging, attach to the browser process that you are currently running at. 7) If everything works, you can deploy your app to the final hosting server by copying the whole folder over.

8) For the final deployment, switch to use full version SQL server. You can attach the ASPNETDB.mdf file to your SQL server, then change your connection string to point to that SQL server instance. connectionString="data source=YOURSQLSERVER; Initial Catalog=YourDBInstanceName;Integrated Security=False;User ID=YOURUSERID; Password=YOURPASSWORD; User Instance=False" You should also consider to encrypt the connection string for security. Read the instruction on how to do this: http://msdn.microsoft.com/en‐us/library/ms178372.aspx

Silverlight Application Deployment 5 Hope this step by step guide can help you understand the problems you are having and make your application deployment process a smoother one.

Silverlight Application Deployment 6 A Guide to Deploying RIA Services Solutions 17 Feb 2011 2:46 AM Introductions. My name is Brad Severtson. I joined the WCF RIA Services team last fall and have worked on the documentation for the upcoming v1 SP1 release. I am a senior programming writer and have worked mainly on WCF and Silverlight technologies. This deployment guide is part of that RIA SP1 doc set. I am releasing the basic parts of this topic early here due to the continued request for guidance on deployment. (I have had to delete some of the links to other SP1 topics, or redirected them to the related current documents, as they will not work until they are published.) This topic has attempted to take all of the existing guidance that has been published on the blogs and provided in videos by the product team (and in particular the Saurabh Pant video on Silverlight TV:http://johnpapa.net/silverlight/sltv51/), several of whose members have also reviewed it as well, and put them into a single procedure that provides a check list of things you should do when deploying a RIA application.

I have worked through it myself more than a few times, of course, mostly with success. There are machines that just seem to have too much *history* or some sort gremlins to configure correctly. I have had gook luck with freshly configured test machines, not as good with machines I have been using for years. So here it is: A Guide to Deploying RIA Services Solutions An outline of the issues that can arise when deploying a RIA Services application and some recommendations on how to deal with them are described in the Troubleshooting a RIA Services Solution(http://go.microsoft.com/fwlink/?LinkId=211605) Please Refer to Below topic.

This also provides some useful conceptual background (in the discussion on excption flow) on the application layers you are dealing with when deploying a RIA Services application.

Silverlight Application Deployment 7 Troubleshooting the Deployment of a RIA Services Solution WCF RIA Services 2 out of 6 rated this helpful ‐ Rate this topic [WCF RIA Services Version 1 Service Pack 2 is compatible with either .NET framework 4 or .NET Framework 4.5, and with either Silverlight 4 or Silverlight 5.] Troubleshooting a WCF RIA Services solution presents a unique challenge because an exception can occur at one of many different layers. You need to understand how these different layers report errors to effectively troubleshoot your application. This topic introduces these layers and provides some techniques for troubleshooting your RIA Services applications when an exception occurs.

Also, many of the issues you may encounter in deploying a RIA Services have been anticipated in the new deployment guide, for details see A Guide to Deploying RIA Services Solutions.

Exception Flow In a RIA Services application, exceptions flow in the following order from the lowest originating layer to the client: 1. Domain Service 2. RIA Services Service Host 3. WCF 4. ASP.NET 5. IIS 6. Silverlight Application

Silverlight Application Deployment 8 Enable Detailed ASP.NET Error Information By default, the customErrors element of a Web.config file is set to RemoteOnly, which means a remote client will not receive the detailed ASP.NET error information. To debug your application, set customErrors to Off so that you can see the detailed ASP.NET error from the client.

Use Fiddler to Inspect Errors Note: Do not make your application publicly available with customErrors set to Off as the error message may expose sensitive information to users.

All exceptions originating from within a domain service are sent to the Silverlight client with an error status code of 200. All exceptions thrown at the WCF layer or lower are sent to the Silverlight client with a status code of 404. You can run the Fiddler HTTP debugger to see the actual error. Browse to the Domain Service Directly Directly browsing to the .svc file for your domain service is often a helpful step to see whether the WCF service is available. However, determining the path to the .svc file is not simple because the .svc does not exist in your solution. You can browse directly to the domain service in a Web browser by using the following pattern: http://[host]/[modified class name for domain service].svc You determine the modified class name by using the fully qualified class name and substituting a dash (‐) for every period .

So a domain service that is named: ExampleApplication.Web.CustomerDomainService has a .svc file named: ExampleApplication‐Web‐CustomerDomainService.svc If this file is hosted on localhost, you browse directly to the file by navigating to: http://localhost/ExampleApplication‐Web‐CustomerDomainService.svc

Silverlight Application Deployment 9 If the service is available, you will see a Web page with information about services and how to test a service. If the service is not available, you will see an error page that may have information which will help you determine the problem. If you receive an error, the exception probably originated at the RIA Services Service Host layer. Override the Domain Service OnError Method When an unrecoverable error occurs during the processing of a DomainService operation, the OnError method is called. You can override this method to inspect errors before they are sent to client.

Use Traditional WCF Tracing Techniques You troubleshoot exceptions at the WCF layer just like you would troubleshoot any WCF service. For more information about diagnostic tracing for WCF services, see Tracing. An exception that originates at the WCF layer will not show up in Fiddler. You can troubleshoot a service exception by attempting to browse to the .svc file. If you can browse to the .svc file without an error, but the service fails at run time, then the exception may originate at the WCF layer. Check ASP.NET and IIS Settings For exceptions thrown at the ASP.NET and IIS layers, information from your RIA Services application is not included in the stack.

You may see exceptions at this level for situations such as:  The Web.config file does not have the correct HttpModule element for the version of IIS you are using.

 WCF is not activated on your Web server.

Silverlight Application Deployment 10 Confirm That the .NET Framework 4 is Installed on the Web Server The .NET Framework 4 must be installed on the Web server for a RIA Services application to work. For more information, see Installing the .NET Framework (http://go.microsoft.com/fwlink/?LinkID=184895). Installing the .NET Framework .NET Framework 4 Other Versions 85 out of 122 rated this helpful ‐ Rate this topic Updated: March 2011 The .NET Framework version 4 redistributable packages are available in two profiles: Full Profile and Client Profile.

To choose the proper profile, see .NET Framework Client Profile. Both profiles provide two types of packages for redistribution:  Stand‐alone executable packages, which contain the required components for deployment, but do not contain language packs.

 Web bootstrapper packages, which download the required components and appropriate language pack from the Web. This topic provides information about these packages, language packs, and installation requirements. It contains the following sections:  Stand‐Alone Redistributable Packages  Web Bootstrapper Packages

Silverlight Application Deployment 11  Installation Requirements  Stand‐Alone Language Packs  Supported Languages Applications and controls written for the .NET Framework require the .NET Framework to be installed on the computer where the application or control runs.

For step‐by‐step instructions for deploying the .NET Framework 4 and its system dependencies across a network, see .NET Framework Deployment Guide for Administrators. For information about deploying the .NET Framework 4 with an application, see .NET Framework Deployment Guide for Developers.

Note You must have administrator privileges to install the .NET Framework 4. Stand‐Alone Redistributable Packages The stand‐alone executable packages contain all the components that are required to install the .NET Framework 4 on the specified target platforms. However, these executables do not contain language packs. You can use the stand‐alone language packs to install language support. The following table lists the stand‐alone redistributable packages for each profile and platform. Stand‐alone package EXE name Profile Target platforms .NET Framework 4 for x86 and x64 dotNetFx40_Full_x86_x64.exe Full x86 and x64 .NET Framework 4 for x86 and IA‐64 dotNetFx40_Full_x86_ia64.exe Full x86 and IA‐64 .NET Framework 4 for x86 dotNetFx40_Full_x86.exe Full x86 only .NET Framework 4 Client Profile for x86 and x64 dotNetFx40_Client_x86_x64.exe Client x86 and x64

Silverlight Application Deployment 12 .NET Framework 4 Client Profile for x86 dotNetFx40_Client_x86.exe Client x86 only The dotNetFx40_Full_x86_64.exe and dotNetFx40_Client_x86_64.exe packages are designed for both x86 and x64 computers. These are the recommended packages for most installation or deployment scenarios. However, these packages do not support IA‐64‐based computers. Use the dotNetFx40_Full_x86.exe or dotNetFx40_Client_x86.exe package if you plan to install the .NET Framework 4 only on x86 computers. Do not use these packages for installation on 64‐bit operating systems. (The Client Profile package is not available for redistribution on IA‐64‐based computers.) Web Bootstrapper Packages The Web bootstrapper packages are Web‐based installers that simplify the installation process.

These lightweight files download the required components from the Web during setup. Each package requires an Internet connection and detects, downloads, and installs required components and the language pack that matches the language of the user’s operating system. You can use the stand‐alone language packs to install additional language support.

The following table lists the Web bootstrapper packages for each profile. Bootstrapper package EXE name Profile Target platforms .NET Framework 4 dotNetFx40_Full_setup.exe Full All CPUs .NET Framework 4 Client Profile dotNetFx40_Client_setup.exe Client x86 and x64 Using the Web bootstrapper, you can manually launch and install the redistributable package on a computer. The redistributable can also be launched and installed as part of the setup program for a .NET Framework 4 application. Installation Requirements The following is a summary of the software and hardware requirements for installing the .NET Framework 4.

For a detailed description of the requirements, see .NET Framework System Requirements.

Software Requirements

Silverlight Application Deployment 13 To install the .NET Framework 4, one of the following operating systems must be installed on the target computer:  Windows 7 family.  Windows Server 2008 R2 family.  Windows Vista family.  Windows Server 2008 family.  Windows XP Home or Microsoft Windows XP Professional, both with Service Pack 3 or later.  Windows 2003 family with Service Pack 2 or later. For Windows Server 2003, you must also install Windows Imaging Component (WIC) on the target computer:  32‐bit Windows Imaging Component  64‐bit Windows Imaging Component Hardware Requirements Requirement Recommended minimum CPU Pentium 1 GHz or higher RAM 512 MB or more Disk space for Client Profile 32‐bit system: 600 MB 64‐bit system: 1.5 GB Disk space for Full Profile 32‐bit system: 850 MB 64‐bit system: 2 GB Stand‐Alone Language Packs

Silverlight Application Deployment 14 The following table provides a list of stand‐alone language pack executable files that contain the localized resources for the specified target platforms. These executables do not contain the language‐ neutral binaries that are required to install the .NET Framework 4 language packs. culture specifies a supported language. Package Name Profile Target platforms dotNetFx40LP_Full_x86_x64.exe Full x86 and x64 dotNetFx40LP_Full_x86_ia64.exe Full x86 and IA‐64 dotNetFx40LP_Full_x86.exe Full x86 only dotNetFx40LP_Client_x86_x64.exe Client x86 and x64 dotNetFx40LP_Client_x86.exe Client x86 only Note The Client Profile language packs are not available for IA‐64‐based computers.

Some examples of these packages are dotNetFx40LP_Full_x86_x64de.exe (for the German ‐ Germany culture) and dotNetFx40LP_Full_x86_x64ja.exe (for the Japanese culture). Supported Languages Concepts .NET Framework Deployment Guide for Developers .NET Framework Deployment Guide for Administrators Change History Date History Reason