第 60 页

will not be loaded.

To remove the application from the Disabled Items list, start the Office application and open the Add-

Ins window that was shown earlier in Figure 19-12 (File . Options . Add-ins from Outlook 2010,

or Tools . Trust Center from Outlook 2007).

Select Disabled Items from the drop-down list

at the bottom of the window and click the

Go button. This displays the Disabled Items

window shown in Figure 19-15. Select your

add-in and click Enable to remove it from this

list. You must restart the application for this

to take effect.

dePloyinG office aPPlications

The two main ways to deploy Office applications are either using a traditional MSI setup project or

using the support for ClickOnce deployment that is built into Visual Studio 2010.

In earlier versions of VSTO, configuring code access security was a manual process. Although

VSTO hides much of the implementation details from you, in the background it still needs to invoke

COM+ code to communicate with Office. Because the Common Language Runtime (CLR) cannot

enforce code access security for non-managed code, the CLR requires any applications that invoke

COM+ components to have full trust to execute.

fiGure 19-14

fiGure 19-15

Deploying office applications .

395

Fortunately, the ClickOnce support for Office applications that is built into Visual Studio 2010

automatically deploys with full trust. As with other ClickOnce applications, each time it is invoked

it automatically checks for updates.

When an Office application is deployed it must be packaged with the required prerequisites. For

Office applications, the following prerequisites are required:

.

Windows Installer 3.1

.

.NET Framework 4, .NET Framework 4 Client Profile, or .NET Framework 3.5

.

Visual Studio 2010 Tools for Office run time

If you are using version 3.5 of the .NET Framework you will also need to package the Microsoft

Office primary interop assemblies (PIAs). A PIA is an assembly that contains type definitions of

types implemented with COM. The PIAs for Office 2007 and Office 2010 are shipped with Visual

Studio Tools for Office, and are automatically included as references when the project is created. In

Figure 19-16 (left), you can see a reference to Microsoft.Office.Interop.Outlook, which is the

PIA for Outlook 2010.

fiGure 19-16

You do not need to deploy the PIAs with your application if you are using .NET Framework 4

because of a new feature called Type Equivalence. When Type Equivalence is enabled, Visual Studio

will embed the referenced PIA as a new namespace within the target assembly. CLR then ensures

that these types are considered equivalent when the application is executed.

396 .

chaPter 19 oFFice buSineSS ApplicATionS

Type Equivalence is enabled for individual references by setting the Embed Interop Types property

to True, as shown in Figure 19-16 (right). Rather than include the entire interop assembly, Visual

Studio will only embed those portions of the interop assemblies that an application actually uses.

This results in smaller and simpler deployment packages.

More information on ClickOnce and MSI setup projects is available in Chapter 48.

suMMary

This chapter introduced you to the major features in Visual Studio Tools for Office. It is now very

easy to build feature-rich applications using Microsoft Office applications because the development

tools are fully integrated into Visual Studio 2010. You can create .NET solutions that customize

the appearance of the Office user interface with your own components at both the application level

and the document level. This enables you to have unprecedented control over how end users interact

with all of the products in the Microsoft Office suite.

PART V

web applications

. ASP NET Web Forms

. ASP NET MVC

. Silverlight

. Dynamic Data

. SharePoint

: chaPter20

: chaPter21

: chaPter22

: chaPter23

: chaPter24

chaPter 25 :. Windows Azure

20

asP.neT Web forms

what’s in this chaPter?

.

The differences between Web Site and Web Application projects

.

Using the HTML and CSS design tools to control the layout of your

web pages

.

Easily generating highly functional web applications with the server-

side web controls

.

Adding rich client-side interactions to your web pages with

JavaScript and ASP NET AJAX

When Microsoft released the first version of ASP.NET, one of the most talked-about features

was the capability to create a full-blown web application in the same way as you would create

a Windows application. The abstractions provided by ASP.NET coupled with the rich tooling

support in Visual Studio allowed programmers to quickly develop feature-rich applications

that ran over the Web in a wholly integrated way.

ASP.NET version 2.0, which was released in 2005, was a major upgrade that included new

features such as a provider model for everything from menu navigation to user authentication,

more than 50 new server controls, a web portal framework, and built-in web site

administration, to name but a few. These enhancements made it even easier to build complex

web applications in less time.

Most of the new features in the latest version of ASP.NET and Visual Studio have focused

on improving the client-side development experience. These include enhancements to the

HTML Designer and CSS editing tools, better IntelliSense support for JavaScript, HTML and

JavaScript snippets, and new project templates.

In this chapter you learn how to create ASP.NET Web Applications in Visual Studio 2010,

as well as look at many of the features and components that Microsoft has included to make

your web development life a little (and in some cases a lot) easier.

400 .

chaPter 20 ASp.neT Web FormS

web aPPlication Vs web site ProJects

With the release of Visual Studio 2005, a radically new type of project was introduced — the Web

Site project. Much of the rationale behind the move to a new project type was based on the premise

that web sites, and web developers for that matter, are fundamentally different from other types

of applications (and developers), and would therefore benefit from a different model. Although

Microsoft did a good job extolling the virtues of this new project type, many developers found it

difficult to work with, and clearly expressed their displeasure to Microsoft.

Fortunately, Microsoft listened to this feedback, and a short while later released a free add-on

download to Visual Studio that provided support for a new Web Application project type. It was

also included with Service Pack 1 of Visual Studio 2005.

The major differences between the two project types are fairly significant. The most fundamental

change is that a Web Site project does not contain a Visual Studio project file (.csproj

or .vbproj),

whereas a Web Application project does. As a result, there is no central file that contains a list of

all the files in a Web Site project. Instead, the Visual Studio solution file contains a reference to the

root folder of the Web Site project, and the content and layout are directly inferred from its files and

subfolders. If you copy a new file into a subfolder of a Web Site project using Windows Explorer,

then that file, by definition, belongs to the project. In a Web Application project you must explicitly

add all files to the project from within Visual Studio.

The other major difference is in the way the projects are compiled. Web Application projects are

compiled in much the same way as any other project under Visual Studio. The code is compiled into

a single assembly that is stored in the \bin directory of the web application. As with all other Visual

Studio projects, you can control the build through the property pages, name the output assembly,

and add pre- and post-build action rules.

On the contrary, in a Web Site project all the classes that aren’t code-behind-a-page or user control

are compiled into one common assembly. Pages and user controls are then compiled dynamically as

needed into a set of separate assemblies.

The big advantage of more granular assemblies is that the entire web site does not need to be rebuilt

every time a page is changed. Instead, only those assemblies that have changes (or have a down-

level dependency) are recompiled, which can save a significant amount of time, depending on your

preferred method of development.

Microsoft has pledged that it will continue to support both the Web Site and Web Application

project types in all future versions of Visual Studio.

So which project type should you use? The official position from Microsoft is “it depends,” which

is certainly a pragmatic, although not particularly useful, position to take. All scenarios are

different, and you should always carefully weigh each alternative in the context of your requirements and

environment. However, the anecdotal evidence that has emerged from the .NET developer community

over the past few years, and the experience of the authors, is that in most cases the Web Application project

type is the best choice.

Creating Web Projects .

401

Unless you are developing a very large web project with hundreds of pages,

it is actually not too difficult to migrate from a Web Site project to a Web

Application project and vice versa. So don’t get too hung up on this decision.

Pick one project type and migrate it later if you run into difficulties.

creatinG web ProJects

In addition to the standard ASP.NET Web Application and Web Site projects, Visual Studio 2010

provides support and templates for several specialized web application scenarios. These include web

services, WCF services, server control libraries, and reporting applications. However, before we

discuss these you should understand how to create the standard project types.

creating a web site Project

As mentioned previously, creating a Web Site project in Visual Studio 2010 is slightly different from

creating a regular Windows-type project. With normal Windows applications and services, you

pick the type of project, name the solution, and click OK. Each language has its own set of project

templates and you have no real options when you create the project. Web Site project development

is different because you can create the development project in different locations, from the local file

system to a variety of FTP and HTTP locations that are defined in your system setup, including the

local Internet Information Services (IIS) server or remote FTP folders.

Because of this major difference in creating these projects, Microsoft has separated out the Web Site

project templates into their own command and dialog. Selecting New Web Site from the File . New

submenu displays the New Web Site dialog, where you can choose the type of project template you

want to use (see Figure 20-1).

fiGure 20-1

402 .

chaPter 20 ASp.neT Web FormS

Most likely, you’ll select the ASP.NET Web Site project template. This creates a web site populated

with a starter web application that will ensure you your initial application is structured in a logical

manner. The template will create a project that demonstrates how to use a master page, menus, the

account management controls, CSS, and the jQuery JavaScript library.

In addition to the ASP.NET Web Site project template, there is an Empty Web Site project template

that creates nothing more than an empty folder and a reference in a solution file. The remaining

templates, which are for the most part variations on the Web Site template, are discussed later in

this chapter. Regardless of which type of web project you’re creating, the lower section of the dialog

enables you to choose where to create the project.

By default, Visual Studio expects you to develop the web site or service locally, using the normal file

system. The default location is under the My Documents/Visual Studio 2010/WebSites folder for

the current user, but you can change this by overtyping the value, selecting an alternative location

from the drop-down list, or clicking the Browse button.

The Location drop-down list also contains HTTP and FTP as options. Selecting HTTP or FTP

changes the value in the filename textbox to a blank http:// or ftp:// prefix ready for you to type

in the destination URL. You can either type in a valid location or click the Browse button to change

the intended location of the project.

The Choose Location dialog (shown in

Figure 20-2) is shown when you click the

Browse button and enables you to specify

where the project should be stored. Note that

this isn’t necessarily where the project will be

deployed, because you can specify a different

destination for that when you’re ready to

ship, so don’t expect that you are specifying

the ultimate destination here.

The File System option enables you to browse

through the folder structure known to the

system, including the My Network Places

folders, and gives you the option to create

subfolders where you need them. This is the

easiest way of specifying where you want

the web project files, and the way that

makes the files easiest to locate later.

fiGure 20-2

Although you can specify where to create the project files, by default the solution

file is created in a new folder under the My Documents/Visual Studio 2010/

Projects folder for the current user. You can move the solution file to a folder

of your choice without affecting the projects.

Creating Web Projects .

403

If you are using a local IIS server to debug your Web Site project, you can select the File System

option and browse to your wwwroot folder to create the web site. However, a much better option

is to use the local IIS location type and drill down to your preferred location under the Default

Web Site folders. This interface enables you to browse virtual directory entries that point to web

sites that are not physically located within the wwwroot folder structure, but are actually aliases to

elsewhere in the file system or network. You can create your application in a new Web Application