The Application Files folder contains the various versions of the application that have been published (see Figure 16-31).
Figure 16-31
When you republish your application using ClickOnce, the content of PhotoViewer.application
, publish.htm
, and setup.exe
are modified, and one new application manifest is created inside a new folder (for instance, PhotoViewer_1_0_0_6
; located within the Application Files folder), containing the new version of deployment files, will be created.
As mentioned, the PhotoViewer.application
application manifest is an XML file that contains detailed information about the current application as well as its version number. It allows the client to know if he needs to update his application.
Deployment Manifest
The deployment manifest — PhotoViewer.exe.manifest
, in this example — is located in the C:\Inetpub\wwwroot\PhotoViewer\Application Files\PhotoViewer_1_0_0_6 directory (assuming that the latest version published is 1.0.0.6; see Figure 16-32). It contains detailed information about the application (such as dependencies and attached files).
Figure 16-32
The PhotoViewer.exe.deploy
file is the executable of your application. Other files in the same directory may include files/databases used by your application. During installation these files will be deployed (downloaded) onto the user's machine.
Where Are the Files Installed Locally?
When the user installs an application onto his computer via ClickOnce, he does not have a choice of where to store the application. In fact, the application is stored on a per-user basis, and different versions of the application are stored in different folders. For example, when I installed the example application on my computer, the application files were stored in:
C:\Documents and Settings\Wei-Meng Lee\Local Settings\Apps\2.0\JGEG6REQ.YQK\C2N9O65K.16D\phot..tion_4f46313378dcdeb5_0001.0000_ff3a6bf346a40e4d
Generally, application files are stored in subdirectories under the C:\Documents and Settings\ \Local Settings\Apps\2.0 folder. To find this directory programmatically during runtime, use the following code snippet:
//---ExecutablePath includes the executable name---
string path = Application.ExecutablePath;
//---Strip away the executable name---
path = path.Substring(0, path.LastIndexOf(@"\"));
This chapter explained how to develop a Windows application to upload and download pictures to and from an FTP server. Several Windows Forms controls were used to build the application's user interface, and you saw how to use the application settings feature in .NET to preserve the status of an application even after it has exited. Finally, the application was deployed using the ClickOnce, which allows applications to be easily updated after they have been deployed.
Chapter 17
Developing ASP.NET Web Applications
ASP.NET (Active Server Pages .NET) is a web development technology from Microsoft. Part of the .NET Framework, ASP.NET enables developers to build dynamic web applications and Web Services using compiled languages like VB.NET and C#. Developers can use Visual Studio 2008 to develop compelling web applications using ASP.NET, with the ease of drag-and-drop server controls. The latest version of ASP.NET is version 3.5.
This chapter explains how to:
□ Display database records using a server control call GridView
□ Perform data binding in an ASP.NET application using the new LinqDataSource
control
□ AJAX-enable your application by using the new AJAX framework in ASP.NET 3.5 and the AJAX Control Toolkit
□ Deploy your web application to a web server
In the early days of the web, the contents of web pages were largely static. Pages needed to be constantly — and manually — modified. To create web sites that were dynamic and would update automatically, a number of server-side technologies sprouted up, including Microsoft's Active Server Pages (ASP). ASP executed on the server side, with its output sent to the user's web browser, thus allowing the server to generate dynamic web pages based on the actions of the user.
These server-side technologies are important contributions to the development of the web. Without them, web applications that users are accustomed to today, such as Amazon.com and eBay.com, would not be possible.
Microsoft ASP began as a public beta (v1.0) in October 1996 as an upgrade to Internet Information Server (IIS) 2.0. In the initial three versions, ASP used a scripting language, VBScript, as the default language. Using a scripting language had its flaws — code is interpreted rather than compiled, and using VBScript as the default language turned some people off (although technically you could configure ASP to use other languages such as JScript and Perl, but this was not commonly done). This interpreted code model of ASP seriously limited performance.
In early 2000, Microsoft introduced the.NET Framework and, together with it, the upgrade of ASP: ASP.NET 1.0 (previously known as ASP+). Over the last few years, ASP.NET has evolved to ASP.NET 3.5.
In ASP.NET, you are not limited to scripting languages; you can use the following .NET languages:
□ C#
□ VB.NET
When a web browser requests a page from a web server, the web server (IIS) first checks whether the request is for an HTML page. If it is, the request is filled by fetching the files from the hard drive and returning them to the client (web browser). If the client is requesting an ASP.NET page, IIS passes the request to the ASP.NET runtime, which then processes the application and returns the output to the client.
ASP.NET pages use the .aspx extension, which ensures that ASP.NET can run side by side with classic ASP, which uses the extension .asp
.
One of the inherent problems with the HTTP protocol is its stateless nature. Put simply, a request made by a user is loaded into memory, fulfilled, and then unloaded. Subsequent requests by the same user are treated just like any other request; the server makes no attempt to remember what the user has previously requested. This stateless nature makes writing web applications a challenge because the application developer must explicitly devise mechanisms to enable the server to remember the previous state of the application. Several mechanisms have been devised over the years, including cookies and query strings for passing information to and from the server and the client.
In classic ASP, you typically need to write pages of code to preserve the state of the page after the user has posted a value back to the server. In ASP.NET, all of these mundane tasks (collectively known as state management) are accomplished by the ASP.NET runtime.
Читать дальше