|Important||This document may not represent best practices for current development, links to downloads and other resources may no longer be valid. Current recommended version can be found here. ArchiveDisclaimer|
What's New in Web Development for Visual Studio
Microsoft Visual Studio 2005 includes the Visual Web Developer Web development tool, which is a set of tools and utilities for creating ASP.NET version 2.0 Web sites. Visual Web Developer represents an evolutionary improvement in support for creating Web sites. Visual Web Developer continues to bring you the productivity benefits of the integrated development environment (IDE) while introducing a wide array of improvements.
The major improvements for this version of Visual Web Developer include the following:
ASP.NET 2.0 support.
Visual Web Developer supports new ASP.NET 2.0 features, including a host of new controls that are introduced in ASP.NET 2.0. In addition, Visual Web Developer adheres closely to native ASP.NET 2.0 features and does not add designer-specific features. For example, Visual Web Developer does not embed designer-specific tags in your ASP.NET 2.0 pages.
More flexible project and deployment options.
Visual Web Developer allows you to create traditional Microsoft Internet Information Services (IIS) applications in the IIS root on local and remote computers and it also supports virtual roots, opening Web sites by using File Transfer Protocol (FTP), and using stand-alone files that reside outside a project. The end result is that it is substantially easier to create and deploy ASP.NET 2.0 applications.
Improved code-behind model.
Visual Web Developer can create pages by using either a new code-behind model or by including code in the ASP.NET page (the .aspx file).
Improved programming capabilities.
Many basic tasks have been greatly simplified. For example, you can create a data-bound page with no coding whatsoever. New ASP.NET 2.0 controls add substantial functionality that used to require you to write your own code. Microsoft IntelliSense and related technologies have been expanded to work virtually everywhere.
The following sections provide a high-level summary of the changes in Visual Web Developer.
For information about new features in ASP.NET 2.0, see.
Web Sites and Projects
Visual Web Developer features a flexible approach to creating Web sites (also called projects and Web applications in previous versions of Visual Web Developer and the Web page designer, respectively). Web sites in Visual Web Developer are not necessarily bound to Microsoft Internet Information Services (IIS) nor to physical folders on the IIS root.
You can now create the following types of Web sites:
You can keep all the files for a Web site in a simple folder. File-system Web sites do not depend on IIS. For details, see.
As in previous versions of Visual Studio, you can create IIS applications that can reside either on the local IIS root or on a virtual directory. You can create virtual folders, as well. For details, see.
You can create applications residing on remote servers that support FrontPage 2002 Server Extensions from Microsoft. This is the model that was used for previous versions of Visual Web Developer and continues to be supported in this version.
You can open Web sites across FTP. For details, see.
ASP.NET Development Server
The Visual Web Developer Web development tool ships with a lightweight test application server, the ASP.NET Development Server, which you can use to test file system Web sites, without having to use IIS. For more information, see.
In the new version of Visual Web Developer, Web sites are not dependent on project and solution files. You can add files to a Web site either in Visual Web Developer or by using Microsoft Windows Explorer, and the files are automatically part of the Web site.
Visual Web Developer still creates project and solution files to store a small amount of project-specific information, such as your IDE settings. Much of the information that was previously stored in project files now either is stored in the Web.config file as standard ASP.NET 2.0 configuration settings or is no longer necessary. The project file stores no information that is required to run the application.
Working without a project model not only makes it possible to add, edit, and remove files outside of Visual Web Developer, it also makes it easier for more than one developer to work together to create a Web site. More than one developer can add or remove files from a Web site without requiring access to a centralized project file that needs to be updated with file information. In addition, it is easier to keep Web site files in a source-control system, such as the Microsoft Visual SourceSafe version control system, because developers do not have to exclusively check out a project file to add files to the Web site.
Dynamic Compilation Model
In Visual Web Developer, Web sites no longer use the compilation model that was used in previous versions, in which the executable code for the entire project was compiled into a single assembly. Instead, by default, the new version uses the dynamic compilation model that is native to ASP.NET 2.0.
Working with Web sites that do not produce an executable assembly as their output has a number of advantages:
You can test Web sites that contain pages still in development—pages that contain compilation errors do not prevent other pages in the Web site from running.
For development on large Web sites, the entire application does not need to be recompiled every time a change is made to a single page or component. When a developer changes a single page, only that page is recompiled when it is next requested.
Different developers can make edits to different pages at the same time without interfering with one another's changes, as could happen when compiling the project to a single assembly, as in Microsoft Visual Studio .NET 2003.
When you test a Web site, the Web site is still compiled (built). However, the compilation step is used as verification that all the pages and their dependencies can be compiled; the output of the compilation process is not used as the basis for running the Web site. This build step is more comprehensive than it was in earlier versions because it validates not only that the code can be compiled but also finds errors in the markup syntax and Web.config file.
Publishing Web Sites
Because some developers do not want to deploy source code with their Web sites, the Visual Web Developer Web development tool provides the option to precompile and deploy a Web site by using the Build Web Site command. The Build Web Site command runs the compiler over the entire Web site (not just the code files) and produces a Web site layout that you can deploy to a production server. The layout includes assemblies for individual pages, which include both the code and the markup for the page (that is, the .aspx files are compiled also).
This feature is not available in Visual Web Developer Express Edition.
The primary benefit of precompiling is that it allows you to deploy only executable code, thus bringing a measure of protection to your intellectual property. In addition, precompiling finds any compile-time errors in the pages or dependent code. Finally, precompiling improves performance and reduces the time it takes for pages in your Web site to render the first time.
Visual Web Developer offers the following enhancements for creating and editing Web pages:
Support for new page features.
The Visual Web Developer Web page designer features WYSIWYG support for new ASP.NET 2.0 page elements, such as master pages. For details, seeand .
Preservation of source code.
Visual Web Developer maintains the HTML formatting of your page when you switch between Design and Source view and when you save files.
Enhanced HTML generation and validation.
Visual Web Developer provides more options for generating and validating the HTML on your page. By default, the Web page designer creates markup that is XHTML 1.1 compatible and new schemas include support for several variations of XHTML. You can set options to determine how strictly Visual Web Developer validates the elements in your page and HTML is also validated more strictly. Additionally, Visual Web Developer provides error information in ToolTips.
Drag-and-drop functionality in Source view.
You can drag controls from the Toolbox while in Source view.
For more information, see.
Visual Web Developer includes a number of improvements to the code editor that help you code more productively, including the following:
Microsoft IntelliSense technology.
Statement completion is now virtually everywhere when you edit Web pages. The IntelliSense technology helps you create code in both code-behind and single-file pages, markup tags, page directives, and so on.
Event drop-down lists.
You can create event-handlers in Source view by using event drop-down lists, as you previously could do only in Code view. The Properties window now allows you to create event handlers for both Visual Basic and C#.
Single-file page support.
The code editor now provides equivalent support for code-behind and single-file ASP.NET 2.0 pages. (For information about changes to the code-behind model, see Improved Code-Behind Model.) Both code models support syntax coloration, IntelliSense technology, and so on.
Classes for which the source code is in the App_Code folder for your Web application are automatically referenced; if you have compiled components, you can place them in the Bin folder to have Visual Web Developer reference them automatically. IntelliSense functionality picks up information about any components that are installed in the App_Code or Bin folder of your application. For details, see.
You have full debugging facilities for local Web sites, including file system Web sites. Debugging is less complex and faster than in previous versions. For details, see.
Improved Code-Behind Model
A significant difference between previous versions of Visual Web Developer and this release is in how code-behind pages work. In Microsoft Visual Studio .NET 2002, when you created a new Web Forms page, Visual Web Developer created an .aspx file with the markup and a separate .vb or .cs file (the code-behind file) for the page's code. The code-behind file defined a complete class that was derived from the Page class.
The Web page designer kept the .aspx file and the code-behind file in synchronization. For example, if you added a Web server control to the .aspx file, the Web page designer created a corresponding instance variable in the code-behind file for that control.
In this version, the code-behind model takes advantage of a new language feature known as partial classes. The code-behind file for a page is not a complete class definition. Instead, it includes only the application code that you need, such as event handlers. The code-behind partial class does not need to include instance variables; ASP.NET 2.0 infers the control instances from the markup at compile time. If you are coding in C#, you do not need to include explicit delegates for event binding, because ASP.NET 2.0 can deduce them from the event attributes (for example, onclick) in the control markup. In Visual Basic, you can add a Handles clause onto the declaration of an event method, as in the previous model, to bind the event to the handler.
The new code-behind model offers a number of advantages over the previous model, as follows:
True separation of code and markup.
In previous versions, the markup and code were stored in separate files. However, because previous versions needed to keep the files in synchronization by using instance variables and event delegates, it was not practical to work with the files separately. For example, it was not practical for a page developer to work on the layout of the page while another developer worked on the code. In this version, this is much more achievable.
Less complexity in referencing controls.
As noted, the new code-behind model does not require explicit instance variables in the code-behind page. Even though previous versions managed the instance variables, it did not do so for all controls—notably for user controls or for some HTML elements that were declared as controls. In this version, because no instance variables are required, all controls, including user controls, are referenced implicitly.
Less generated code.
The new code-behind model contains virtually no generated code beyond the class definition itself. There are no reserved areas in the code-behind that the editor might overwrite.
Visual Web Developer supports new ASP.NET 2.0 controls, which offer new functionality, which results in significantly greater productivity. In addition to hosting new controls, the Web page designer includes improvements to help you work more easily with controls. Highlights include the following:
More consistent and powerful editing model.
The overall model for working with controls is more consistent between controls and allows you to perform many more actions without having to use the Properties window or edit the declarative syntax of a control.
Visual display of controls.
The Web page designer has improved support for rendering controls; for example, user controls are now rendered visually in Design view.
As you work with controls, they display a Smart Tag menu (a floating, shortcut menu of tasks) for the current control. Typical actions that are offered by task-based editing include editing templates and setting up data binding.
The Web page designer provides a simplified and more intuitive interface for creating and editing templates on complex controls, such as the DataList and GridView controls.
It is now much easier to create and edit HTML tables in the Web page designer. For details, see.
You can now extend controls in powerful new ways. As before, you can create user controls and custom controls. This release of the Visual Web Developer Web development tool provides improved support for user controls, including WYSIWYG rendering in Design view and Properties window support.
You can extend the run-time behavior of controls by creating adapters, which define the output of the control for a specific device or browser. At run time, ASP.NET 2.0 determines the type of device that generated the request and invokes a control adapter to render the appropriate output for that device for a given control. By creating an adapter for a control and a specific class of device, you can customize the output for that control for the device. Adapters are especially useful for creating custom rendering for new devices. For more information, see.
If you develop custom controls, you now have improved support for hosting your control in a Web page designer, including the following:
Classes that allow you to add region-based editing to your controls at design time.
Support for task-based editing, so that you can define verbs (tasks) that are exposed for your control by using a shortcut menu in the Web page designer.
Template-editing services that simplify adding support for templates in your controls.
Controls can take advantage of tool-based services for improved interaction with their hosting environment. For example, controls have access to the page directive, the project system, and the current document.
Data Controls and Data Binding
Working with data is an important part of many ASP.NET 2.0 Web pages, and Visual Web Developer includes many improvements to make data access easier to implement and manage. The overall goal for data binding in ASP.NET 2.0 is to be able to accomplish a wide variety of data-binding scenarios without having to write any code at all. This version supports this goal and extends it by providing wizards that help you configure data binding and create data components.
Data Binding with Data Source Controls
The model for binding controls on the page to data sources has been improved considerably. The data-binding model for Microsoft Visual Studio .NET 2002 required that you add data components, such as a connection and dataset objects, on the page. Then, you needed to write code to manage data binding to data controls, such as the DataList and DataGrid controls.
To simplify data binding, ASP.NET 2.0 introduces data source controls. Data source controls provide a single object in which you can declaratively define the following:
Queries (a SQL statement, stored parameter name, or the names of methods to invoke on an object).
Parameters—you can define parameters declaratively and specify that they get their values from a control on the page, from a query string, from session variables, or from other sources.
Behavior options (depending on the data source control), such as paging and caching.
In general, you do not need to work directly with the objects that are used to manage data access, such as datasets or data readers. Data source controls create data components under the covers. You do not work with those components, but you do need to be aware of them when you want to use a feature, such as paging, that depends on choosing between a dataset and a data reader.
ASP.NET 2.0 provides data source controls for different types of data stores, including SQL (for OLE DB and Open Database Connectivity [ODBC] databases), XML files, and business objects. All data source controls expose the same interface to data controls on the page, so that controls, such as the DataList and Repeater controls, and the new GridView control, can bind the same way to any data source control, regardless of the underlying data store that they represent, and then display data on the page. The result is that you can use the full array of ASP.NET 2.0 data controls to work with a wide variety of data sources.
To help you create and configure data source controls, the Visual Web Developer Web development tool includes wizards that help you to create connections, define queries or specify methods to call, and configure parameters.
Enhanced Data Controls
All data controls in ASP.NET 2.0 have been enhanced to work with data source controls. Instead of pointing a control at a dataset or data reader, you reference a data source control. The data control and data source control then work together to manage data binding automatically, so that in most cases you do not need to write code to perform data binding.
As a result, you can take advantage of automatic data binding in any data-bound control. In addition, ASP.NET 2.0 introduces new data controls that provide additional functionality. These include the following:
The GridView control, which is the successor to the DataGrid control.
The GridView control automates many of the features of the DataGrid control, so that you do not need to write code for editing, sorting, or paging. For situations in which you want to customize the control's behavior, you can continue to use the object model that you are familiar with from the DataGrid control.
The DetailsView control displays one record at a time and allows you to edit, delete, and insert records.
You can also page through multiple records.
The FormView control is similar to the DetailsView control, but allows you to define a free-form layout for each record.
The FormView control is like a DataList control for a single record.
You can continue to use the DataGrid control, although it is superseded by the GridView control. Existing pages that use the DataGrid control work as is. As with other data controls, the DataGrid control has been enhanced to interact with data source controls.
Two-Way Data Binding
The combination of data source controls, declarative parameters, and enhanced data controls provides the ability to create two-way data binding without having to write code. In data source controls, you can define queries or method names to use for updates. Data controls, such as the GridView, DetailsView, and FormView controls, support edit and delete modes (and for some controls, insert mode) that can automatically interact with the data source controls to write data to the data source.
Connection String Storage
To help make your Web sites more maintainable and more secure, you can keep connection strings in the Web.config file in a new section that has been designed specifically for connection string storage. When you use the Visual Web Developer Web development tool to create or configure data source controls, you can specify that the connection string be stored in the Web.config file. If you change data sources, you can easily change the connection string in one location rather than having to update all data components on all pages with a new connection string. For added security, you can encrypt the connection string section of the Web.config file. For details, see.
Two-Tier and Three-Tier Data Access
The earlier data binding model encouraged the creation of two-tier data solutions, in which the Web pages interacted directly with the database to fill a dataset and to bind controls to it. The new model continues to make it easy to work in a two-tier structure. For example, the SqlDataSource control connects directly to a database and executes SQL statements or stored procedures to read and write data.
The new data binding model also makes it much easier to create a three-tier structure in which data access is handled by a middle-tier business object. The ObjectDataSource control interacts with a business object by calling methods on the object to retrieve and update data. Data controls on the page can bind to the ObjectDataSource control as they do to other data source controls, such as the SqlDataSource control.
The Visual Web Developer Web development tool includes a data component wizard that helps you create a custom object that contains methods to read and update data. Alternatively, you can create your own middle-tier object that contains methods. As long as your custom object exposes methods with the appropriate signatures, you can reference it from an ObjectDataSource control. For details, see.
Backward Compatibility for Data Access
The Visual Web Developer Web development tool continues to support pages that use the data binding model from previous versions. Pages that contain datasets and other components run as they did before, and you can open them and edit the pages in the Web page designer. Visual Web Developer does not remove the data components and does not convert the components to data source controls.
Data components, such as datasets and data connections, are not displayed in the Web page designer in Visual Web Developer. Therefore, you can neither set nor examine their properties by using the Properties window. However, you can still edit the code that is used to instantiate the data components and set their properties.
For more information, seeand .
Converting Existing Web Sites
Visual Web Developer can automatically convert your existing projects to the new streamlined Web site layout. The conversion process preserves the functionality of your application and the project options that apply. Existing code-behind Web pages are converted to a new code-behind model that preserves the separation of HTML and code, but provides a simplified structure. For more information, see.
After conversion, you can use the Web page designer to work with pages and controls that were developed with previous versions of Visual Web Developer.
Web Application Projects
The new Web application project model provides the same Web project semantics as the Visual Studio .NET 2003 Web project model. This includes a structure based on project files and a build model based on compiling all the code for a project into a single assembly. In addition, the new project type supports many of the new features of Visual Studio 2005 (such as class diagrams, test development, and generics) and of ASP.NET 2.0 (such as master pages, data controls, membership and logon, role management, Web parts, personalization, site navigation, and themes).
For more information about Web application projects, see.