升级早期ASP.NET的Beta版程序到Beta 2时的错误信息提示
If you're updating ASP.NET Beta 1 sites to the new Beta 2 bets check out this helpful link before you try and figure out what some of those cryptic new error messages mean.
http://www.hanselman.com/blog/UpdatingFromEarlyASPNETBetaBuildsToBeta2.aspx
Thanks again Scott for some great time saving info!
If you're upgrading some mid-BETA or CTP ASP.NET 2.0 code and you get some cryptic messages like
- c:\WINDOWS\Microsoft.NET\Framework\v2.0.50215\Temporary ASP.NET Files\chapter 10 - 8 - csharp\3e344bac\60be3ec8\-sngkrtn.0.cs(265): error CS0115: 'ASP._Default_aspx.FrameworkInitialize()': no suitable method found to override
- 'ASP._Default_aspx.FrameworkInitialize()': no suitable method found to override c:\WINDOWS\Microsoft.NET\Framework\v2.0.50215\Temporary ASP.NET Files\chapter 10 - 8 - csharp\3e344bac\60be3ec8\-sngkrtn.0.cs 265
- 'ASP._Default_aspx.GetTypeHashCode()': no suitable method found to override c:\WINDOWS\Microsoft.NET\Framework\v2.0.50215\Temporary ASP.NET Files\chapter 10 - 8 - csharp\3e344bac\60be3ec8\-sngkrtn.0.cs 272
You'll need to make a few changes. First, you probably already updated your ASPX Markup.
In your ASPX page:
OLD: <%@ Page Language="C#" CompileWith="Default.aspx.cs" ClassName="Default_aspx" %>
NEW: <%@ Page Language="C#" codefile="Default.aspx.cs" Inherits="Default_aspx" %>
In your ASPX.CS source file:
OLD: public partial class Default_aspx
NEW: public partial class Default_aspx : Page
No free derivation any more, you have to explictly derive from a
class that ulitmately derives from System.Web.UI.Page. It is that
derivation that will get ride of the override compiler errors seen
above. This who post also applies to pages written in VB.
升级早期ASP.NET的Beta版程序到Beta 2的兼容性考虑和版本转换
http://www.gotdotnet.com/team/changeinfo/default.aspx
Compatibility Considerations and Version Changes
The following document describes changes between versions of the .NET Framework that might affect the backward or forward compatibility of your application. Information is also provided about the types of changes that can cause incompatibilities, ways to modify your application to work around incompatibilities, and how to test and run your application on different versions of the .NET Framework. This information is comprehensive but not exhaustive, so contact Product Support Services (PSS) if you need further assistance.
Obsolete APIs in version 2.0 (beta 1)· For a list of APIs that are marked obsolete in V2.0 (beta 1) of the .NET Framework, download this zip file, and extract the contents to a directory on your machine. The file contains static htm and xml files, which simply list the obsolete APIs and their messages.
Version 1.1 to Version 2.0 (beta 1) issues· For a list of changes that can affect an application written for the .NET Framework version 1.1 when running on the .NET Framework version 2.0, see the Version 1.1 to Version 2.0 (beta 1) Backwards Breaking Change List.
· For a list of public API Changes (which may, or may not be breaking) between V1.1 and V2.0 (beta 1), please see API Changes.
Version 1.0 to Version 1.1 issues· For a list of changes that can affect an application written for the .NET Framework version 1.0 when running on the .NET Framework version 1.1, see the Version 1.0 to Version 1.1 Backwards Breaking Change List.
· For a list of changes that can affect an application written for the .NET Framework version 1.1 when running on the .NET Framework version 1.0, see the Version 1.0 to Version 1.1 Forwards Breaking Change List.
· For a list of public API Changes changes (which may, or may not be breaking) between V1.0 and V1.1, please see API Changes.
What it means to make an API Obsolete
For details on making an API obsolete, what it means to obsolete an API, and why we obsolete APIs at all, please review Frequently Asked Questions About Making an API Obsolete.
Compatibility and Breaking Changes
The .NET Framework attempts to maintain backward and forward compatibility between versions. However, a change to the .NET Framework that improves security, correctness, or functionality might also raise compatibility issues.
Backward compatibility means an application written for the .NET Framework version 1.0 can execute on version 1.1. The .NET Framework provides the highest degree of support for backward compatibility. Most applications that work on the current version of the .NET Framework will work on the next version of the .NET Framework.
Forward compatibility means an application written for the .NET Framework version 1.1 can execute on version 1.0. Although forward compatibility is supported by the .NET Framework, an application that uses a type or member specific to version 1.1 will never run properly on version 1.0. This is not a forward incompatibility because the application can never be expected to work. If you want your application to run properly on both versions of the .NET Framework, then your application should only use types and members in version 1.0.
Breaking Changes
A breaking change is either a binary or behavioral change to types or members in the .NET Framework that makes an application backward or forward incompatible. A backward breaking change makes an application written for the .NET Framework version 1.0 execute improperly on version 1.1, while a forward breaking change makes an application written for the .NET Framework version 1.1 execute improperly on version 1.0.
Backward breaking changes are primarily made to implement security enhancements, while forward breaking changes are generally introduced to fix behavioral errors in version 1.0.
Binary Breaking Changes
A binary breaking change means the signature of a type or member is changed. The change can range from renaming a method parameter to renaming the method itself or changing the type of a return value. Binary changes are usually backward and forward incompatible.
Although there are binary changes in the .NET Framework version 1.1, the effect of these changes is minimal. This is because the modifications apply only to types or members in version 1.0 that were reserved or technically unusable.
Behavioral Breaking Changes
A behavioral breaking change means the way a type or member operates is changed. A behavioral breaking change is often more subtle and harder to identify than a binary breaking change. Behavioral breaking changes can be backward, forward, or both backward and forward incompatible.
Behavioral breaking changes are seldom made to the .NET Framework except to correct coding errors or enhance reliability and security.
Redirecting Applications
By default, an application only works with the version of the .NET Framework with which it was compiled. In this case, no configuration file is necessary to execute the application. However, if you want an application built with one version of the .NET Framework to execute on one or more different versions of the .NET Framework, then you must use an appropriate configuration file.
Specifying the version of the .NET Framework the application is to use is called redirecting the application. An application can be redirected to use only a particular version of the .NET Framework, or one of a set of candidate versions selected by order of preference. You can create the configuration file automatically using Visual Studio .NET, or manually using the following information.
If your application does not have a configuration file, create one in the same directory as your application. Name the configuration file the same name as your application with ".config" appended to the name. For example, if the name of an application is MyApp.exe, then the name of the corresponding configuration file is MyApp.exe.config.
Configuration File Tags
Redirect your application by specifying the appropriate configuration file tags. In this example, the <requiredRuntime> tag is used to redirect your application to a computer that only has the .NET Framework version 1.0 installed.
<startup>
<requiredRuntime imageVersion="v1.0.3705" version="v1.0.3705" />
</startup>
For the .NET Framework version 1.0, the configuration file needs to redirect any dependent assemblies your application requires because version 1.0 does not automatically reference dependent assemblies. As a result, your configuration file can be very large. In this example, an assembly is redirected to the .NET Framework version 1.0.
<dependentAssembly>
<assemblyIdentity name="Accessibility" publicKeyToken="b03f5f7f11d50a3a" culture=""/>
<bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535" newVersion="1.0.3300.0"/>
</dependentAssembly>
For the .NET Framework version 1.1, the configuration file is smaller because the runtime automatically references dependent assemblies on your behalf. The ability of the .NET Framework to automatically reference dependent assemblies is called unification. That means you only need a simple configuration file to unify an application and its referenced assemblies with one version of the .NET Framework.
Specify one or more <supportedRuntime> tags in your configuration file to indicate the versions of the .NET Framework your application can execute on. The order of the tags indicates the preferred order of candidate .NET Framework versions. That is, the first tag indicates the foremost version you want to use; if that version is not installed, then the second tag indicates the second most preferred version you want to use, and so on.
The following example redirects an application built with the .NET Framework version 1.0 to execute on version 1.1.
<startup>
<supportedRuntime version="v1.1.4322" />
</startup>
If the .NET Framework version 1.1 is installed on your computer, specify multiple <supportedRuntime> tag entries to specify multiple versions of the .NET Framework. If you want an application to run on the .NET Framework version 1.0, you still need a <requiredRuntime> tag and the redirection tags for each assembly your application uses.
In the following example, the .NET Framework version 1.1 is preferred, but if that version is not available version 1.0 is used.
<startup>
<requiredRuntime imageVersion="v1.0.3705" version="v1.0.3705" />
<supportedRuntime version="v1.1.4322" />
<supportedRuntime version="v1.0.3705" />
</startup>
Configuration Files for Mixed Versions of Applications and Frameworks
The following section describes the part of the configuration file required to run various versions of your application on various versions of the .NET Framework.
To run an application built with the .NET Framework version 1.0 on version 1.0, no redirection is necessary. This is the default behavior of a .NET Framework version 1.0 application.
To run an application built with the .NET Framework version 1.0 on version 1.1, include a configuration file with your application like the following:
<?xml version ="1.0"?>
<configuration>
<startup>
<supportedRuntime version="v1.1.4322" />
</startup>
</configuration>
To run an application built with the .NET Framework version 1.0 on either version 1.0 or version 1.1, include a configuration file with your application that includes two <supportedRuntime> tags, and a <requiredRuntime> tag. The first <supportedRuntime> tag redirects to .NET Framework version 1.0. The <requiredRuntime> tag redirects to version 1.0.
Include redirection sections for all assemblies referenced by your application. Redirect these assemblies to version 1.0 since these sections are not used by version 1.1.
For example:
<startup>
<requiredRuntime imageVersion="v1.0.3705" version="v1.0.3705" />
<supportedRuntime version="v1.0.3705" />
<supportedRuntime version="v1.1.4322" />
</startup>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Regcode"
publicKeyToken="b03f5f7f11d50a3a"
culture=""/>
<bindingRedirect
oldVersion="0.0.0.0-65535.65535.65535.65535"
newVersion="1.0.3300.0"/>
</dependentAssembly>
<!-- Include a section for each assembly to be redirected. -->
</assemblyBinding>
</runtime>
To run an application built with the .NET Framework version 1.1 on version 1.1, no redirection is necessary. This is the default behavior for a .NET Framework version 1.1 application.
To run an application built with the .NET Framework version 1.1 on the .NET Framework version 1.0, include a <requiredRuntime> tag in your configuration file that points to the .NET Framework version 1.0. Include all necessary redirections for assemblies your application references.
To run an application built with the .NET Framework version 1.1 on version 1.1 or version 1.0, include a configuration file with your application that includes two <supportedRuntime> tags, and a <requiredRuntime> tag. The first <supportedRuntime> tag redirects to .NET Framework version 1.1. The <requiredRuntime> tag redirects to the .NET Framework version 1.0.
Include redirection sections for all assemblies referenced by your application. Redirect these assemblies to the .NET Framework version 1.0 since these sections are not used by .NET Framework version 1.1.
Testing Your Application
Test your application on all versions of the .NET Framework you want to support. In particular, test your application on all versions of the .NET Framework that your application might run on. This means you will need to recompile your application or change configuration settings to test your application on different versions of the .NET Framework.
Warning Updating a Visual Studio .NET version 1.0 Project
If you open a project built with Visual Studio .NET version 1.0 in Visual Studio .NET version 1.1, you will get a warning saying that the project will be automatically upgraded to Visual Studio .NET version 1.1 and your application will be upgraded to execute on the .NET Framework version 1.1. After the project is opened in Visual Studio .Net version 1.1, you cannot open it in Visual Studio .NET version 1.0. This is true even if you do not rebuild your application. Furthermore, opening your project in the later version of Visual Studio does not automatically guarantee that your application will still compile and run.
To run a .NET Framework version 1.0 application on version 1.1 (Backward Compatibility), perform your test on a separate computer that only has .NET Framework 1.1 installed.
1. Compile your original application on the .NET Framework version 1.0.
2. Create the necessary configuration file to target the .NET Framework version 1.1.
3. Copy the compiled binary files to a computer with only the .NET Framework version 1.1 installed.
4. Run the application.
To run a .NET Framework version 1.1 application on version 1.0 (Forward Compatibility), perform your test on a separate computer that only has the .NET Framework version 1.0 installed.
1. Compile your original application on the .NET Framework version 1.1.
2. Create the necessary configuration file to target the .NET Framework version 1.0.
3. Copy the compiled binary files to a computer with only the .NET Framework version 1.0 installed.
4. Run the application. If the application fails, it might be because you are using some functionality specific to the .NET Framework version 1.1. In that case, you must modify your application to only use .NET Framework version 1.0 functionality.
