Troubleshooting Conversion to Visual Web Developer
When you use Microsoft Visual Web Developer to open a Web application project that was created in earlier versions of Microsoft Visual Studio .NET, Visual Web Developer automatically converts the Web application to the format used in ASP.NET version 2.0.
Note
For details about the conversion process, see Web Project Conversion from Visual Studio .NET.
Under some circumstances, your Web applications will behave differently after conversion. This topic describes the most common of these situations and suggests solutions. For more information on migrating troubleshooting, you can also consult the migration information at the ASP.NET Development Center for Migration.
This topic describes the following conversion issues:
Controls Render Different Markup After Conversion
Markup Validation Produces Errors
Page Events Are Raised Twice After Conversion
Ambiguous Classes Reported During Compilation
Errors Related to Changes in the Code-Behind Page Model
Parsing Errors
Excluded Files No Longer Excluded
Partially Converted Solutions for Mixed Project Types
Opening a Web-Based Site as a File-System Site
Client-side IDs Get Deleted From the Code-Behind File
Circular Reference Error
Controls Render Different Markup After Conversion
In ASP.NET 2.0, unless the browser is identified as not supporting XHTML features, the Page class and ASP.NET Web server controls render markup by default that is compatible with the XHTML 1.0 Transitional standard. The conversion wizard automatically sets the mode attribute of the xhtmlConformance element to Legacy. After conversion, elements might be rendered slightly differently than they were in earlier versions of ASP.NET. In most cases, the differences in rendering have no effect on the functionality of the application. However, if you have client script that relies on specific tags or attributes, your application might not work as it did previously.
For more information, see ASP.NET and XHTML.
Markup Validation Produces Errors
After migration, the default markup validation schema is set to Internet Explorer 6.0. This means that the editor compares markup in your page against a schema that defines what Microsoft Internet Explorer 6.0 considers valid HTML. This step is taken to make the transition to Visual Web Developer easier. It is a good practice to modify your markup so that your application pages validate using the XHTML 1.0 Transitional validation schema.
For details on how to change the validation schema, see How to: Select Validation Schemas for HTML Editing in Visual Web Developer.
Page Events Are Raised Twice After Conversion
The conversion process removes the AutoEventWireup attribute of the @ Page directive. The default value for this attribute is true, which means that the page automatically raises events that have the name Page_event. If a page had explicitly set the AutoEventWireup attribute to false, after the conversion, events on the page will be automatically raised. If the page includes another explicit way to raise the event, such as the Handles keyword in Visual Basic, the event might be raised twice. To resolve this issue, add AutoEventWireup="false" to the @ Page directive.
Ambiguous Classes Reported During Compilation
After converting a project, it is possible that the compiler will report that a class is ambiguous, which means that it was imported from more than one namespace. For example, if a converted project creates an instance of the Cache class, the compiler reports that the class resides in both the System.Net and the System.Web.Caching namespaces.
In cases like these, the .NET Framework version 2.0 contains a new class that has the same name as an existing class. To correct this problem, locate any references to the class in your code and then prepend the class name with the namespace name, creating a fully qualified reference.
Errors Related to Changes in the Code-Behind Page Model
Converting projects with .aspx pages that access class protected members in code-behind classes might generate exceptions. This is caused by the change in the code-behind model in the .NET Framework 2.0. In earlier versions of the .NET Framework, pages were derived classes of code-behind classes. However, in ASP.NET 2.0, code-behind classes define partial classes that are used with the .aspx page during page generation to create the resulting compiled page.
A common scenario in which you might encounter this conversion issue is in an application that defines shared layout components in a base class code-behind class. You can get the same shared layout functionality by using user controls or master pages, or by using the CodeFileBaseClass attribute of the @ Page directive. For more information about developing user controls, see ASP.NET User Controls Overview. For more information about using master pages, see ASP.NET Master Pages Overview.
Parsing Errors
The conversion wizard reports parsing errors on .aspx files that could not be parsed. The causes of parsing problems fall into the following categories:
The .aspx page was not correctly formatted before the conversion wizard was run.
A CodeBehind or Src attribute of the @ Page directive was not found.
The code-behind file referenced in an .aspx page was not found.
An .aspx file is listed in the project file (.csproj or .vbproj, for example) but is not in the project directory. If the file is not part of the project, this error can be ignored.
Excluded Files No Longer Excluded
In previous versions of Visual Studio, you had the option to include or exclude files in a Web project. Additionally, a file could be excluded from the project build by setting its build action to None. The migration wizard treats these two cases differently. The migration wizard converts files in a Web project that are not marked as excluded. The migration wizard does not convert files that are not part of the project build -- files configured with their build action set to None.
After the conversion process is complete, you can delete any previously excluded files or rename them with an extension that is not used in Visual Studio, such as the .exclude extension. If a file in a project within the Web project was not converted, check to make sure its build action is not set to None.
Files that have their associated build action set to None generate an error message in the conversion report. For more information on the conversion report, see Migration Conversion Report Format.
Partially Converted Solutions for Mixed Project Types
In Microsoft Visual Studio 2005 and previous versions it is possible have a solution that is composed of both Web projects and client projects such as class libraries or Windows applications. If you are using an express edition of Microsoft Visual Studio 2005, then only the part of the solution that pertains to the express edition can be converted. For example, if you use the conversion wizard in Visual Web Developer 2005 Express Edition, then you will only be able to convert the Web projects of solutions you open, regardless of what other project types the solution contains. The resulting converted solution will only be partially converted. To fully convert a solution containing mixed project types, use Visual Web Developer 2005, Visual Studio 2005, or Visual Studio 2005 Team System.
Opening a Web-Based Site as a File-Based Site
The recommended way to open a Web site created in a previous version of Visual Studio is to use the Open Web Site menu option in Visual Web Developer 2005. You can then choose to open the site as a file-based site, a local Microsoft Internet Information Services (IIS) site, a File Transfer Protocol (FTP)-deployed site, or a remote site. Opening a Web-based site as a file-based site will cause IIS metadata information to be lost. In particular, information about subfolders marked as virtual directories will not be retained. The conversion report will report a warning when a Web-based site is converted to a file-based site.
It is recommended that you close the Web site and reopen it using the Open Web Site command and selecting the Local IIS tab. For more information on how to use the migration wizard, see How to: Convert a Visual Studio .NET Project to Visual Studio 2005. For more information on the conversion report, see Migration Conversion Report Format.
Client-Side IDs Get Deleted From the Code-Behind File
If you have markup that uses a client-side ID attribute (for example in an HTML div element) that has the same name as a member variable declared in the code-behind page, then during conversion the ID tag in the markup is removed.
To address this issue, review your markup and code before conversion and look for conflicts in names between client-side ID attributes and member variables, and change them so they are using different names.
Circular Reference Errors
The conversion process adds @ Reference directives to code-behind pages that reference other pages or user controls. There might be situations where this creates a circular reference. To aid in troubleshooting, you can set the batch attribute of the compilation element to False. The default batch attribute value is True. Setting the batch to False might eliminate circular reference issues. Longer term, you can redesign the pages or user controls to use an abstract base class defined in a class stored in the App_Code folder and set the batch attribute back to True.
See Also
Tasks
How to: Select Validation Schemas for HTML Editing in Visual Web Developer
Concepts
Web Solution and Project File Conversion