Creating an ASP.NET Web Site with Silverlight Content:
Although Silverlight does perfectly well on its own, you can also develop, test, and deploy it as part of an ASP.NET web site. Here’s how to create a Silverlight project and an ASP.NET web site that uses it in the same solution:
1. Select File -> New -> Project in Visual Studio, choose the Visual C# group of project types, and select the Silverlight Application template. It’s a good idea to use the Create directory for solution option, so you can group together the two projects that Visual Studio will create—one for the Silverlight assembly and one for ASP.NET web site.
2. Once you’ve picked the solution name and project name, click OK to create it.
3. When asked whether you want to create a test web, choose the first option, Add a new Web. You’ll also need to supply a project name for the ASP.NET web site. By default, it’s your project name with the added text _Web. Finally, click OK to create the solution.
There are two ways to integrate Silverlight content into an ASP.NET application:
(1) Create HTML files with Silverlight content: You place these files in your ASP.NET web site folder, just as you would with any other ordinary HTML file. The only limitation of this approach is that your HTML file obviously can’t include ASP.NET controls, because it won’t be processed on the server.
(2) Place Silverlight content inside an ASP.NET web form: To pull this trick off, you need the help of the Xaml web control. You can also add other ASP.NET controls to different regions of the page. The only disadvantage to this approach is that the page is always processed on the server. If you aren’t actually using any server-side ASP.NET content, this creates an extra bit of overhead that you don’t need when the page is first requested.
Of course, you’re also free to mingle both of these approaches, and use Silverlight content in dedicated HTML pages and inside ASP.NET web pages in the same site. When you create a Silverlight project with an ASP.NET web site, you’ll start with both. For example, if your Silverlight project is named SilverlightApplication1, you can use SilverlightApplication1TestPage.html or SilverlightApplication1TestPage.aspx. The HTML file is identical to the test page in the ordinary Silverlight-only solution you saw earlier. The .aspx file is an ASP.NET web form that uses ASP.NET’s Xaml web control to show your Silverlight application. The end result is the same, but the Silverlight control creates the test page markup dynamically, when it’s processed on the server. (This extra step gives you a chance to use your own server-side code to perform other tasks when the page is initially requested, before the Silverlight application is downloaded and launched.) Below figure shows how a Silverlight and ASP.NET solution starts out.
Along with the two test pages, the ASP.NET web site also includes a Default.aspx page (which can be used as the entry point to your ASP.NET web site) and web.config (which allows you to configure various web site settings).
Silverlight and ASP.NET provide essentially the same debugging experience as a Silverlight-only solution. When you run the solution, Visual Studio compiles both projects and copies the Silverlight assembly to the ClientBin folder in the ASP.NET web site. (This is similar to assembly references—if an ASP.NET web site references a private DLL, Visual Studio automatically copies this DLL to the Bin folder.) Once both projects are compiled, Visual Studio looks to the startup project (which is the ASP.NET web site) and looks for the start page (which is SilverlightApplication1TestPage.aspx). It then launches the default browser and navigates to the start page.
Silverlight Compilation and Deployment:
Now that you’ve seen how to create a basic Silverlight project, add a page with elements and code, and run your application, it’s time to dig a bit deeper. In this section, you’ll see how your Silverlight is transformed from a collection of XAML files and source code into a rich browser-based application.
Compiling a Silverlight Assembly:
When you compile a Silverlight project, Visual Studio uses the same csc.exe compiler that you use for full-fledged .NET applications. However, it references a different set of assemblies and it passes in the command-line argument nostdlib, which prevents the C# compiler from using the standard library (the core parts of the .NET Framework that are defined in mscorlib.dll). In other words, Silverlight applications can be compiled like normal .NET applications written in standard C#, just with a more limited set of class libraries to draw on. The Silverlight compilation model has a number of advantages, including easy deployment and vastly improved performance when compared to ordinary JavaScript. Your compiled Silverlight assembly includes the compiled code and the XAML documents for every page in your application, which are embedded in the assembly as resources. This ensures that there’s no way for your event handling code to become separated from the user interface markup it needs. Incidentally, the XAML is not compiled in any way (unlike WPF, which converts it into a more optimized format called BAML).
Your Silverlight project is compiled into a DLL file named after your project. For example, if you have a project named SilverlightApplication1, the csc.exe compiler will create the file SilverlightApplication1.dll. The project assembly is dumped into a ClientBin folder in your project directory, along with a few other important files:
(1) A PDB file: This file contains information required for Visual Studio debugging. It’s named after your project assembly (for example, SilverlightApplication1.pdb).
(2) AppManifest.xaml: This file lists assembly dependencies.
(3) Dependent assemblies: The ClientBin folder contains the assemblies that your Silverlight project uses, provided these assemblies have the Copy Local property set to true. Assemblies that are a core part of Silverlight have Copy Local set to False, because they don’t need to deployed with your application. (You can change the Copy Local setting by expanding the References node in Solution Explorer, selecting the assembly, and using the Properties window.).
(4) TestPage.html: This is the entry page that the user requests to start your Silverlight application.
(5) A XAP file: This is a Silverlight package that contains everything you need to deploy your Silverlight application, including the application manifest, the project assembly, and any other assemblies that your application uses.
Deploying a Silverlight Assembly:
Once you understand the Silverlight compilation model, it’s a short step to understanding the deployment model. The XAP file is the key piece. It wraps the units of your application (the application manifest and the assemblies) into one neat container. Technically, the XAP file is a ZIP archive. To verify this, rename a XAP file like SilverlightApplication1.xap to SilverlightApplication1.xap.zip. You can then open the archive and view the files inside.
The XAP file system has two obvious benefits:
(1) It compresses your content: Because this content isn’t decompressed until it reaches the client, it reduces the time required to download your application. This is particularly important if your application contains large static resources , like images or blocks of text.
(2) It simplifies deployment: When you’re ready to take your Silverlight application live, you simply need to copy the XAP file to the web server, along with TestPage.html or a similar HTML file that includes a Silverlight content region. You don’t need to worry about keeping track of the
assemblies and resources.
Thanks to the XAP model, there’s not much to think about when deploying a simple Silverlight application. Hosting a Silverlight application simply involves making the appropriate XAP file available, so the clients can download it through the browser and run it on their local machines. However, there’s one potential stumbling block. When hosting a Silverlight application, your web server must be configured to allow requests for the XAP file type. This file type is included by default in IIS 7, provided you’re using Windows Server 2008 or Windows Vista with Service Pack 1. If you have Windows Vista without Service Pack 1, you have an earlier version of IIS, or you have another type of web server, you’ll need to add a file type that maps the .xap extension to the MIME type application/xsilverlight-app. For IIS instructions, see http://learn.iis.net/page.aspx/262/silverlight.
Now, you get enough basic knowledge of Silverlight. For more articles, videos, blogs please visit http://silverlight.net/
No comments:
Post a Comment