Visual Studio .NET allows managed (.NET) web projects to be written in C#, VB.NET, or J#. Each of these languages has four web project templates: ASP.NET Web Application, ASP.NET Web Service, ASP.NET Mobile Web Application, and Empty Web Project. (Mobile Web Applications are not available in VS.NET 2002.)
The ASP.NET Web Application template is used for building web applications that will be accessed from a normal web browser. The ASP.NET Web Service template is used to build web servicesprograms that present a programming interface instead of a user interface, but which are still accessed using HTTP. The ASP.NET Mobile Web Application template is designed for building web applications that will be accessed from a web browser on a mobile device such as a PDA or mobile phone. The Empty Web Project template can be used to build any kind of web application.
These four template types are very similar to one anotherthey manage and build their files in much the same way. The only differences between them are the default set of files that are added to the project initially. For the ASP.NET Web Application project, the main file added to the project is an ASP.NET Web Form named WebForm1.aspx, while for a Mobile Web Application, the main form is called MobileWebForm1.aspx. (Mobile Web Applications also have an additional reference to System.Web.Mobile.) For ASP.NET Web Service projects, the main file is Service1.asmx, which acts as the main web service entry point. An Empty Web Project contains no files at all to start with.
VS.NET treats all of these project types in exactly the same way once they have been created. So for the rest of this section, we will not distinguish between the different types of managed web projects.
You create new managed web projects using the New Project dialog (Ctrl-Shift-N) as usual. When you have selected a managed web project type, you must enter a URL into the Location text box, as shown in Figure 4-2.
When you click OK, VS.NET immediately communicates with IIS to see if a web application with the specified name exists. If not, VS.NET will create a new application that takes its name from the last part of the location name (i.e., the string typed in after the last forward slash). For example, if the string http://localhost/app1 is entered into the Location text box, VS.NET will create a new web application called app1. It will not create a virtual directory howeverwhen VS.NET creates a new application in this way, it just adds a nonvirtual directory underneath the web server's home directory. So if the home directory were the default c:\inetpub\wwwroot, VS.NET would create the new directory at c:\inetpub\wwwroot\app1.
You can optionally prepare the IIS web application before creating the project. This can be useful since it enables you to control the location of the files on the web server. For example, you could create a new virtual directory and associated web application called app2 that maps to a physical directory called, say, e:\MyApp. When you use VS.NET to create a new web project using the path http://localhost/app2, instead of creating a new application, VS.NET will happily use the existing one. See Chapter 1 for more information about pre-creating folders for Web projects.
If you have an existing web application, you can create a VS.NET project for the application and its files, rather than having to build a new application from scratch. You can do this by building an Empty Web project (based upon your language of choice) and using the location of your existing web application in the Location box of the New Project dialog. Once you have created the project, it will, of course, be empty as far as VS.NET is concerned, so the next step will be to add the files in the web application to the VS.NET project. To do this, click on the Show All Files button in the Solution Explorer window (see Figure 4-3) to show all the files that already exist in the application, and then add the files you are interested in working with by right-clicking on them and selecting the Include in Project option.
If you have a web application in which you want to create a project, but you don't recall the exact name, you can use the Browse button from the New Project dialog. This shows the Project Location dialog box, which allows you to browse for projects.
The Project Location dialog is normally used for browsing through the filesystem. However, it can also browse web servers. There is a Tools menu in the upper-righthand corner of this dialog, and it provides an Open from Web Server... option. This brings up the Connect to Web Server dialog, into which you can type the URL of the web server where you want to create the new project. If you supply a URL that contains only the server name (e.g., http://localhost/), VS.NET will show you a list of all the directories on the server, as Figure 4-4 shows. The dialog indicates a directory that is already a web application by embedding a small globe icon in its folder icon.
You can pick the directory in which you would like to create the new project. VS.NET will then use that directory for creating all the files based upon the project type you selected. If you select a directory that does not have its own web application, VS.NET will create a new application for that directory.
When you create a managed web project, the project files are not kept on your local hard disk, as they are for other VS.NET project types. Only the solution files (.sln and .suo) are kept in a local folder. All the other files (including the .xxproj file) are kept on the web server.
Although the master copies of a web project's files all live on the web server, VS.NET keeps a local copy of all the web project files in a special folder called the web project cacheit needs local copies in order to be able to edit and compile files. The default folder for the project cache is a folder called VsWebCache under your user account's Document and Settings folder. You can change the location of this folder using the Tools Options dialog. Select the Projects folder in the lefthand pane of the Options dialog, and then choose the Web Settings subitem. The cache directory can then be set in the Offline Projects section on the righthand side. (This is a per-user settingthere is no way to configure the cache directory on a per-project basis.)
In ASP.NET, we are discouraged from having all of our source code inside of .aspx files, intermingled with HTML code. Instead, the .aspx file should contain only user interface elements, while any dynamic server-side behavior should be in a separate source file associated with the .aspx page. This separate source file is known as the codebehind fileit contains the server-side code behind the HTML frontend. (This same concept is also applied to other ASP.NET-related files, such as the global.asax and any .asmx or .ascx files.) Use of codebehind is not mandatoryyou are free to create a spaghetti-like tangle on a single page if you preferbut it is almost always better to separate user interface from implementation.
To use codebehind, you must put a special attribute into the @Page directive in your .aspx file (or the analogous directive for other file types). The attribute is Inherits, which specifies the name of a type. ASP.NET will use this type as the base class for the class that it builds dynamically based upon the HTML and code contained in the .aspx file.
This named type obviously needs to be available to ASP.NET at runtimeit can build a class derived from a type only if it has access to that type. One way of doing this is to use the Src attribute. The Src attribute names a source file, and whenever either the .aspx file or the file referenced in the Src attribute is modified, ASP.NET will recompile both files. The intended usage model is that the source file contains the source for the page's base class.
However, although VS.NET uses codebehind, it does not use the Src attribute. Instead, it compiles the source file that contains the base class for the .aspx page into the main assembly for the web application. VS.NET will copy this assembly into the web application's bin subdirectory, and ASP.NET automatically loads any assemblies in that directory into the web application's AppDomain. This means that when ASP.NET compiles the .aspx page, it will already have loaded the application's main assembly and will therefore already have access to the base class. So VS.NET has no need to use the Src attributeit needs to use only the Inherits attribute.
Although it does not use the Src attribute, VS.NET does place an attribute in the @Page directive that refers to the source file: the Codebehind attribute. ASP.NET ignores this attributeit is present only for VS.NET's benefit. It tells VS.NET which source file is associated with a particular content file.
By default, VS.NET hides the codebehind files in the Solution Explorer. However, if you want to see them, you can click on the Show All Files button. This will cause the Solution Explorer to show you all the source files associated with particular content filescodebehind files appear as children of their corresponding content files in the tree. (You do not need to do this merely to edit the codebehind file. If you right-click on an .aspx file in the Solution Explorer and select View Code, VS.NET will open the codebehind file instead of the .aspx file.)
Source files do not have to be codebehind files in a web projectyou can also add raw source files as you would with any other kind of project. These files get built into the main application assembly as usual.
If someone else has created a project for an existing web application, you may need to open it in order to work on the files in the project. To do this, you select File Open Project from Web. This brings up the Connect to Web Server dialog in which you can type the URL of the web server from which you want to open up the project. This dialog presents a view of the web applications on the web server like the one shown in Figure 4-4. Once you open the correct web application folder, you should find the project file (with a .csproj, .vbproj, or .vjsproj file extension) on the server. When you open it, VS.NET will create a local solution file for you (unless you are adding this to an existing solution).
You build a managed web project in the same way as all other projects, using Build Build Solution (Ctrl-Shift-B). However, VS.NET performs some extra work when building a web project. As usual, VS.NET takes all of the source files in your project and builds them into a single assembly. (Since the compilers cannot work directly from a web server, this compilation takes place in the folder in the local web cache that corresponds to this project.) Once compilation is complete, VS.NET copies the results to the actual web application.
To get debugging to work, you need to make sure that you are building a debug configuration (which causes VS.NET to create a .pdb file for your assembly). The configuration can be selected from the Solution Configuration drop-down list in the Standard toolbar or you can use the Build Configuration Manager... menu option. (The Debug solution will be selected by default for a newly created web project, so you will normally need to select only the Debug configuration if you have previously selected a different configuration.) You will also need to tell ASP.NET that you want to debug your application. The simplest way to do this is to make sure that the web.config in your application has the debug attribute on the compilation element set to true. Example 4-1 shows a suitable minimal configuration file. (Note that the default web.config generated by VS.NET for a new web project will already contain a compilation element with debug set to true, so again, you will not need to take any special action on a newly created .NET web application.)
<?xml version="1.0" encoding="utf-8" ?> <configuration> <system.web> <compilation debug="true" /> ...other configuration stuff here... </system.web> </configuration>
Setting this attribute will tell the ASP.NET compilation system to generate debugging information for dynamically compiled files (e.g., .aspx, .asmx). This enables source-level debugging of such files in VS.NET.
Once the debug symbols are in place, you can debug this project like any other. See Chapter 3 for detailed information about debugging.
Note that when you debug a web application, the application effectively becomes unusable for anyone elsewhenever you suspend execution in the debugger, the application will not be able to respond to requests until you allow it to continue.
IIS 6 can mitigate this with application pools, but usually the simplest solution is for developers to have their own copies of the application on their machines' local web servers.
One of the choices you need to make when working with a web project is whether to use File Sharing or FrontPage Server Extensions to access your project files on the web server. By default, VS.NET will use File Sharing.
When using File Sharing, VS.NET copies your files to the web server using normal Windows File Sharing. If your project points to a remote web server, you will need to have a share open on the server (VS.NET looks for a wwwroot$ share by default). For this to work, the web server will have to be able to recognize your Windows login credentials. This will usually mean that the web server must be in the same Windows domain as you. (Or if you are not using domain authentication, the web server will need to have an account with the same name and credentials that you use.)
If the machine you are trying to connect to does not have a share named wwwroot$, you will get the dialog box shown in Figure 4-5. With this dialog, you can either fill in the correct share name or switch the project to use FrontPage Server Extensions (FPSE). Microsoft advises that if you are using File Sharing, you should use the wwwroot$ share name, so although it is possible to use this dialog to select something else, VS.NET can sometimes get confused by this. So you should really use this dialog only to select between File Sharing and FPSE.
If you switch from File Sharing to FPSE, then instead of using SMB to connect to the files on the web server, VS.NET will use its FPSE libraries to communicate with the web server via the FPSE HTTP protocol.
The main advantage of FPSE over File Sharing is that FPSE can work better when the web server that hosts your web application is not on your local network. When the web server is on your local network, this is not likely to be an issueyou will typically have a large amount of bandwidth, which will make using SMB fast, and the web server will likely be in the same Windows domain as you, so security will not be an issue. If your server is remote, however, FPSE may be a better bet since it uses HTTP. This is less likely to be tripped up by firewalls or other security configuration issues and is also generally faster than Windows File Sharing over longer distances. However, VS.NET prefers the use of File Sharing, so you should use that if possible.