Greeting Cards
However, you need to change the security settings of your hard drive so the web application can write the temporary images to a folder under the web root. These settings are discussed after the next two sections that describe installing the application using the supplied installer or through a manual process.
Using the Installer
The companion CD and the code download come with an automatic installation application in the form of a Microsoft MSI package. To install the application using this MSI file, open the folder Chapter 11 - Greeting Cards\Installer on the CD-ROM or from the downloaded zip file.
Next, double-click setup.exe and keep clicking Next until the application is installed completely. Finally, click Close to dismiss the installation wizard.
Now that the application is installed, you need to tweak some security settings. Refer to the section “Configuring the Application” that follows directly after the next section that describes manual installation.
Manual Installation
Manual installation is probably just as easy as installing the application with the supplied installer. For a manual installation, all you need to do is extract the contents of the supplied zip file to a folder on your hard drive. To do this, open the folder Chapter 11 - Greeting Cards\Source on the CD-ROM or from the zip file you downloaded from www.wrox.com. Next, open the zip file Chapter 11 - Greeting Cards.zip and extract its contents to any folder you want (for example, C:\Projects). Make sure you extract the file while maintaining the directory structure. How this option is called depends on your extracting utility, but you should look for a feature called Use Folder Names or something similar to that. In the end, you should end up with a folder like C:\Projects\GreetingCards that in turn contains a few files and folders.
To view and test the code, open Visual Studio Web Developer Express edition and choose File Open Web Site. Make sure that File System is selected in the left-hand pane and then browse to the folder where you just extracted the contents of the zip file. Select the folder and then choose Open. Visual Web Developer will load the files and folders in the folder you selected, so you can look at the source for the Greeting Cards application.
With the extraction done, the final step is to configure the security settings for the application. This step is discussed next.
Configuring the Application
Configuring the Greeting Cards application is straightforward and easy. All you need to do is change security settings so the application can write to the temporary folder and configure the mail server. The security settings are discussed first, followed by the mail server.
Configuring Security Settings
The Greeting Cards application needs a place to store the temporary files that are uploaded, created, and saved by the various methods in the Toolkit. To make it easy to change where these files are stored, the application uses a single application setting to denote this temporary path. By default, this folder is a
Chapter 11
Temp folder inside the Images folder of the application as is shown by the following code from the Web.config file:
<add key=”MaxImageHeight” value=”480”/>
<add key=”TempImagesFolder” value=”~/Images/Temp”/> </appSettings>
To allow the application to write to this folder, you’ll need to change the security settings for the account that the web server uses. If you’re using the integrated Developer Web Server that comes with Visual Web Developer, this account is your own account that you use to log on to your machine. If you’re running the site under IIS, the account is called ASPNET on Windows 2000 and Windows XP or Network Service on Windows Server 2003. To change the security settings, follow these steps:
1.Open a Windows Explorer and locate the Images folder of your application. If you used the installer, this path is C:\Inetpub\wwwroot\GreetingCards\Images by default. If you did a manual install and followed the instructions, the path is C:\Projects\GreetingCards\Images.
2.Inside the Images folder, right-click the Temp folder (if you don’t see the folder, you can create a new folder called Temp first), choose Properties, and click the Security tab. The dialog in Figure 11-15 appears.
If you don’t see a Security tab, close the dialog and then choose Tools Folder Options in Windows Explorer. Then switch to the View tab and scroll all the way to the bottom of the Advanced settings list (see Figure 11-16). Make sure that Use Simple File Sharing (Recommended) is not checked.
Click OK to close the dialog and open the Properties for the Temp folder again.
Figure 11-15
Greeting Cards
Figure 11-16
3.Depending on your system and configuration, you may have more or fewer users listed in the Group or User Names list. Click the Add button to add the user account described in the introduction of this section. You should either add your own account or the ASPNET or Network Service account. When you have typed the account name, click OK to add it to the list. It should now be visible in the list with Group or User Names that you saw in Figure 11-15.
4.Next, in the Group or User Names list, click the account you just added and then in the Permissions list at the bottom half of the screen, make sure that at least Modify, Read, and Write are selected. As soon as you click Modify, some of the other options are automatically selected for you.
5.Click OK to dismiss the Security dialog. You should now be able to run your application and create images with the Greeting Card application. If you get an error, make sure you added the right account for the right folder, and that you selected the right permissions.
Configuring the Mail Server
Because the application sends out e-mail, you need to configure the name of your outgoing mail server in the Web.config file. To change that setting now, open that file and scroll all the way down to the bottom. You’ll see the following <mailSettings> node:
<system.net>
<mailSettings>
<smtp deliveryMethod=”Network”>
<network host=”smtp.YourProvider.Com” port=”25”/> </smtp>
Chapter 11
</mailSettings>
</system.net>
</configuration>
Change the host attribute of the <network> node to the name of the server you use for outgoing mail. If your mail server supports authentication, you can set the userName and password properties of this node as well.
With this last modification, the application is ready to run. Either browse to http://localhost/ GreetingCards when you installed the application with the supplied installer or press F5 in Visual Web Developer to start the application.
If you’re feeling adventurous, head to this book’s download page at www.wrox.com to find a list of possible enhancements to the Greeting Cards application and the Toolkit. You’ll learn how to extend the Toolkit by adding support for drop shadows on the text on the images. You’ll also learn how to add one image to another so you can display your company’s logo on each image that gets uploaded in the Greeting Cards application.
Summar y
This chapter covered a lot of ground on working with images through the GDI+ library. Although GDI+ is a very large subject, you have seen how to perform basic imaging tasks, such as resizing, rotating, cropping, and adding text to images. These basic tasks should create a solid basis on which you can build to increase your imaging skills in .NET applications. To recap, you have seen how to do the following:
Use the Greeting Card application to upload and alter a custom image that can be sent by e-mail.
Use the UploadHandler class to allow a user to upload files from a local computer to the web server. This UploadHandler is not limited to images alone; it can also handle other kinds of documents.
Use the .NET System.Drawing namespace to perform operations on images, such as rotating, cropping, and resizing.
Create a reusable framework of user controls that split up a more complex application into smaller pieces that can be reused in other applications separately.
Create a reusable toolkit with code that can be used in many applications. By creating a DLL from the code in the Toolkit folder, you can create a reusable binary file that can be incorporated in other applications very easily.
Toward the end of the chapter, you saw how to install the Greeting Cards application, either with an automated installer or manually. The automated procedure is useful if you want to get the application up and running on a production server in no time. The manual process is useful if you want to look at the code and make modifications to it.
12
The Bug Base
If you have ever done any web or other software development before, it’s likely that the applications you wrote contained bugs. No matter how good a programmer you are, it’s almost impossible to write an application that does not contain a single bug. Some bugs are caused by logic or coding errors and some are the result of a difference between the expectations of the project’s client and the programmer. Yet other bugs may not be discovered until you actually start using the application. For example, usability or performance issues are often discovered only once the end-users get hold of the web site or application. Somehow, you need to keep track of those bugs, so they can be fixed in a next release or service update.
If you’re a one-man development shop, you might be doing all your bug-tracking using sticky notes on your monitor with text such as “Fix security bug in login module; don’t allow access to just anyone.” But once your application starts to grow, or you work in a team of developers, this is no longer a viable solution. If you’re working for a large software development company, you may be working with advanced bug tracking tools like the Work Item Tracking feature from the new Microsoft Visual Studio 2005 Team System Edition (http://msdn.microsoft.com/vstudio/teamsystem), or tools like Bugzilla (www.bugzilla.org) or SourceGear’s Dragnet (www.sourcegear.com/dragnet). However, these types of applications often cost a lot of money, or may require considerable amounts of time, knowledge, and resources to set up and maintain.
The Bug Base introduced in this chapter is positioned right in between the sticky notes on your monitor and an advanced bug tracking application. The Bug Base allows you and your team members to collaboratively file, change, and report on bugs through a web interface. The Bug Base can be installed on a server connected to the local network or the Internet, so it can be reached from any convenient location. It uses a role-based security mechanism, allowing you to determine who in your team can perform which operation. The member accounts and role settings and all other application settings are configurable within the web application itself so you can change them anywhere, anytime.
The first section of this chapter briefly guides you though the application, showing you the main screens and functionality. The section that follows digs into the design of the Bug Base. It describes the classes used in the application and how they interact. The section “Code and Code Explanation” analyzes all of the important files used in the application. If you want to know how to set up and use the Bug Base, you’ll find installation instructions in the section “Setting up the Bug Base” later in this chapter.
Chapter 12
Using the Bug Base
The Bug Base application allows you to carry out four important tasks: filing bugs, changing bugs, reporting about bugs, and application maintenance. The role-based security mechanism implemented in the Bug Base grants access to each of these features to the roles defined in the system. Each user should be assigned to at least one role so they can log in and perform one of these tasks.
The database that comes with this chapter’s code (available for download at www.wrox.com) has five member accounts already defined, one for each of the four roles in the application and a super user:
Username |
Password |
Description |
|
(case sensitive) |
|
Tester |
Tester123# |
A tester can only file new bugs, change his or her |
|
|
own bugs, or add comments to existing bugs. |
Developer |
Developer123# |
A developer can perform the same actions as a |
|
|
tester, but in addition a developer can also change |
|
|
existing bugs and change their status. |
Manager |
Manager123# |
A manager has the same rights as a developer, |
|
|
but can also use the reporting functionality. |
Administrator |
Administrator123# |
An administrator has the same permissions a |
|
|
tester has. However, an administrator can also |
|
|
access the maintenance section to manage appli- |
|
|
cations, features, and members. |
SuperUser |
SuperUser123# |
The super user has been assigned to each of the |
|
|
four roles. This allows you to view the functionality |
|
|
for all roles without constantly having to log in |
|
|
and out. In normal operations, you wouldn’t use |
|
|
this account. |
Once you’re logged in, you see the homepage appear (shown in Figure 12-1), which displays a welcome message and the main menu that appears at the top of each page.
Figure 12-1
The Bug Base
On this screen you see the main menu, right below the logo. This menu has four menu items: Bugs, Reporting, Maintenance, and Help. It also has two icons on the sides that take you back to the homepage (the home icon on the left) and that display the sitemap (the icon on the right). Depending on the roles you are assigned to, some menu items are invisible.
To file a new bug, choose File New Bug from the main Bugs menu as shown in Figure 12-2.
Figure 12-2
Before you can file a bug, you need to select an active application to work with, so you’re taken to the SwitchApplication.aspx page first. This page shows a simple drop-down list with the available applications and an Apply button. Choose any application from the drop-down list and click the button. The page depicted in Figure 12-3 appears.
At the upper-right corner of the page in Figure 12-3 you see how you’re logged in (as a Tester in this example), which roles you’re assigned to (Tester), and which application you’re working with (Instant Results - BugBase). The rest of the page allows you to enter information about a bug. The Feature of a bug describes the section of the application in which the bug occurs. Features are application-specific and are manageable in the Maintenance section described later. The Reproducibility of the bug indicates if and how often the bug is reproducible. This can be important for developers to know when they try to reproduce the bug and find the problem. The Frequency describes the scope of the bug by asking how many users will encounter the bug. With the Severity drop-down the bug filer can indicate the impact of the bug, ranging from a simple spelling mistake to loss of data and application crashes.
After you make valid selections in each of the drop-downs, you need to type a title and a description of the bug. The text area has been filled with a short template for the bug report, making it easier for users to describe the problem in a detailed manner.
Once you click the Insert bug button you see the Bug List page, as shown in Figure 12-4.
The Bug Base
You can limit the list to Active or Inactive bugs using the drop-down menu to the top-left of the bug list. Inactive bugs are bugs that no longer need attention or work, such as Fixed and Deferred bugs. The Reporting and Search pages that are discussed later allow you to refine the list with bugs even further, by searching for only Deferred or Fixed bugs, for example. In the Maintenance section you can select which status items of a bug determine whether or not the bug gets closed.
If you click the Edit button for a bug you get a screen similar to the File New Bug window (see Figure 12-5). This time two new drop-downs have appeared, allowing you to change the current status for the bug from New to another appropriate status and to change the bug’s priority. The Priority drop-down list displays the numbers 1 through 5, where 1 means a bug that needs to be fixed right away, and 5 indicates a less important bug. The Status drop-down holds items like Open, Fixed, and Deferred.
Figure 12-5
When you select Search Bugs from the ever-present main Bugs menu (shown in Figure 12-2) you can search for specific bugs in the currently selected application. With the item Switch Application on that same menu you can select another application to work with.
The Reports item under the main menu item Reporting allows you to generate reports about all bugs in the application regardless their status or application they are filed against. This menu is available only to members in the Manager role.
Under the main menu item Maintenance you’ll find various menu items that allow you to change application settings. You can change and create applications and features for those applications. You can also change the items that appear in the drop-downs for Status, Frequency, Reproducibility, and Severity. You’ll find the latter three under the Other Bug Properties menu, which is also a sub-menu item of the main Maintenance menu, shown in Figure 12-2. Figure 12-6 shows a list of all the Frequency Items in the system with the first one being edited:
Chapter 12
Figure 12-6
To change the Reproducibility and Severity, choose the appropriate item from the drop-down list on the Bug Properties Maintenance page shown in Figure 12-6.
The final page in the Maintenance section allows you to assign Members to roles and applications. This way, you have fine control over which member is allowed to do what in the Bug Base.
At the very right of the main menu you’ll see the Help menu and a site map icon. The site map icon takes you to the site map page, and you can get help about the Bug Base with the Help menu.
Design of the Bug Base
The Bug Base is designed as a three-layered architecture, which means that presentation, business logic, and data access are each placed in different layers or tiers. As is often the case with ASP.NET applications, the presentation layer consists of a number of .aspx pages and .ascx user controls that use ASP.NET server controls. These pages talk to classes defined in the business layer that in turn talk to the data access layer to get information in and from the database.
The new code model of ASP.NET 2.0 makes it easy to separate the business and data access logic from the presentation tier with the introduction of the App_Code folder. Any code placed in this folder is automatically compiled and available to all your other files in your application, including .aspx pages and other code files. If you’re using the full version of Visual Studio 2005 (for example, the Standard or Team System edition) you can move this code to a separate Class Library project, which you can then include in your
