Maximizing.ASP.dot.NET.Real.World.ObjectOriented.Development [Electronic resources] نسخه متنی

Multiple Projects and References

In Chapter 4, "Application Architecture," we explored the idea of dividing up our applications into layers. Visual Studio makes this easier than ever by grouping projects together as solutions. A project can be a Web site or a class library, among other things, and you can work on them together as a solution.

Figure 14.1 shows the Solution Explorer with a Web project at the top and a class library right below it. You'll notice that the assembly from the class library appears in the Web project's /bin folder.

By creating a reference from one project to another, you can access all of the compiled code from the referenced project. Figure 14.2 shows how to add a reference from the Web project shown in the Solution Explorer to another project. Right-clicking the project name and choosing Add Reference brings up the dialog.

Using multiple projects can help you divide up your project into layers where appropriate. For example, you can create a class library that does the "heavy lifting" and logic for your application and not worry about the implementation of the user interface. Good class design also lets you unit test the classes in your class library (something we'll go into more in Chapter 16, "Testing, Deployment, and Code Management"). By getting your logic absolutely right and thoroughly tested, implementing the user interface becomes less error-prone.

Working Locally

Visual Studio 2005 allows for the development of sites in folders, outside of your local IIS installation. The IDE turns on its own Web server to host your application. Working locally, therefore, is as easy as picking a folder anywhere on your computer.

Visual Studio 2002 and 2003 require Web apps to live in a folder in IIS. This process works by associating a URL such as http:// localhost/folder with a path to the administrator file share, /wwwroot$. Generally this share maps to c:\inetpub\wwwroot, unless you've altered it. If Visual Studio can't match these two locations as the same place, it won't allow you to create a project there.

Working from Another Server on Your LAN

In Visual Studio 2005, trying to execute code from a remote server in its Web server won't work for security reasons. A better solution is to use some kind of source control (such as Visual Source Safe) to check out the code and work with it on a local folder.

Working remotely with Visual Studio 2002 and 2003 operates a lot like the local scheme, using a URL and an administrator share to access the code. To make it work, the machine you're working from must have administrator privileges on the remote server to access the file share. The fastest and easiest way to accomplish this on a Windows network is to put your user account in the remote server's administrator group. That's something you may have to "negotiate" with your IT department.

Working on a server in this manner also requires that remote debugging be installed on the server if you plan to use the debugger.

Working from a Web Server

All versions of Visual Studio can work remotely on a Web server by using Microsoft FrontPage extensions. These extensions retrieve files via HTTP, cache them locally, and send them back to the server when you save them. There are two drawbacksthe retrieving and saving of files can be slow, and you can't use the debugger in this fashion.

In order to compile assemblies and edit files, Visual Studio saves the files locally on your computer. The default location for this is c:\Documents and Settings\YourUserName\VSWebCache. A subfolder is created for every site you work on, including your local IIS folders. When you issue a build command in 2002 or 2003, all of the .cs (or .vb) files are used as the source code for the compiled assembly. The assembly is saved in the /bin folder of this temporary cache of your project, and then uploaded to the Web server.

Other files that are not compiled (.aspx files, for example) are also stored in the same location. However, if you happen to be editing someone else's work, that file will not exist in your cache structure until you open it.

Working with a Source Control Provider

Source control is a means of versioning and sharing code among a team of developers. Generally speaking, a central database keeps copies of the code files, and new copies are created every time the file is changed. Developers check out files to alter them. A checked out file can't be (or rather shouldn't be) checked out by other developers. In some cases, the source control can track the changes between two developers and then merge the changes.

Visual Source Safe has shipped with Visual Studio for years, and it went relatively unchanged through several versions until Visual Studio 2005. The latest version works on a local network as well as the Web. Visual Studio has the built-in capability to access source control from the solution explorer. In Figure 14.1, you can see the little padlock icons next to files, which indicate that a file is checked in.

A number of other products such as Source Gear's Vault are compatible with Visual Studio.