For the most current version of the Release Candidate (RC) Readme, click here.
For Beta 2, the latest version of the Readme is available here.
For Beta 1, the latest version of the Readme is available here.
1.2 Supported Operating Systems:
1.4 Other System Requirements:
The .NET Framework 1.0 cannot be installed after the .NET Framework 4 is installed. The .NET Framework 1.0 must be installed before the .NET Framework 4 is installed.
To resolve this issue:
1) Open the add and remove programs section of the Control Panel.
2) Uninstall the .NET Framework 4 Extended.
3) Uninstall the .NET Framework 4 Client Profile.
4) Install the .NET Framework 1.0.
5) Install the .NET Framework 4.
The default response file for Visual Basic (vbc.rsp) and C# (csc.rsp) contains a set of common assemblies that the command-line compilers will consider referenced, even if you have not explicitly specified a reference (/r) to those assemblies. These response files are only available in the full version of the .NET Framework, and are not included in the .NET Framework 4 Client Profile. This means that when you use vbc.exe or csc.exe directly on the command line of a computer that has only the .NET Framework 4 Client Profile installed, you must specify all references explicitly.
This issue does not affect developers who have installed Visual Studio 2010 on their computers because the full version of the .NET Framework 4 is included. It also does not affect developers who are building through MSBuild because MSBuild already requires project references to be specified explicitly.
To resolve this issue:
There are two workarounds:
The .NET Framework 1.0 cannot be installed after the .NET Framework 4 Client Profile is installed. The .NET Framework 1.0 must be installed before the .NET Framework 4 Client Profile is installed.
To resolve this issue:
1) Open the add and remove programs section of the Control Panel.
2) Uninstall the .NET Framework 4 Client Profile.
3) Install the .NET Framework 1.0.
4) Install the .NET Framework 4 Client Profile.
On a computer that has IIS 7 or IIS 7.5 enabled and has the .NET Framework 4 Beta 2 installed, uninstalling the Beta 2 release leaves unused "isapiCgiRestriction" entries in the applicationHost.config file. This occurs on Windows Vista, Windows Server 2008, and Windows 7. The unused entries do not affect Web server functionality. The .NET Framework 4 RC can be safely installed on the computer because it will update "isapiCgiRestriction" entries.
To resolve this issue:
Delete the unused "isapiCgiRestriction" entries from the applicationHost.config file. However, this step is not required because the entries that remain after uninstallation do not affect the functionality of the product or the ability to install the RC release.
There are no known issues.
The classes in the System.Device.Location namespace have changed since the Beta 2 release of the .NET Framework 4, and these changes are not yet reflected in IntelliSense or in the offline documentation.
To resolve this issue:
See the online documentation at http://msdn.microsoft.com/en-us/library/default.aspx for more information about the following, and other, changes:
Partial trust applications deployed by using ClickOnce and containing a configured compatibility element in the application manifest (for more information, see http://msdn.microsoft.com/en-us/library/dd371711(VS.85).aspx) default to Windows Vista compatibility behavior on Windows Vista and Windows 7.
To resolve this issue:
Make the application a full trust application
In Solution Explorer, right-click a project and then click Properties.
Click the Security tab.
Select the Enable ClickOnce Security Settings check box.
Click This is a full trust application.
After you install the .NET Framework 4 on a client computer or a server that is running Windows 7 and that has IIS 7.5 enabled, the option to configure ASP.NET configuration files for different application pools stops working. This occurs because installing the .NET Framework 4 causes a slight change to the default behavior for CLR initialization. When the .NET Framework 4 is installed, IIS 7.5 on Windows 7 calls into a native ASP.NET 4 DLL to perform CLR initialization, and this initialization logic does not include the ability to use different configuration files.
To resolve this issue:
Because the CLR initialization logic is fundamentally the same for .NET Framework 4 and for IIS 7.5 (except for the configuration-file side effect), you can reconfigure IIS 7.5 so that it no longer delegates CLR initialization to ASP.NET 4. You can do this in either of two ways.
Option 1
----------
In the IIS 7.5 applicationHost.config file, set the default value of the "managedRuntimeLoader" attribute to an empty string, as shown in the following example:
<applicationPools>
<applicationPoolDefaults managedRuntimeLoader="" />
</applicationPools>
Option 2
----------
In the IIS 7.5 IIS_Schema.xml file, set "defaultValue" in the attribute named "managedRuntimeLoader" to an empty string. For example, the attribute might originally read like this:
<attribute name="managedRuntimeLoader" type="string" defaultValue="webengine4.dll" />
Change it to this:
<attribute name="managedRuntimeLoader" type="string" defaultValue="" />
On Windows XP and Windows Server 2003 (all versions), if you unregister ASP.NET 4 from IIS and then re-register it, the IIS MMC displays an empty value for the ASP.NET version list on the ASP.NET tab. The following sequence of steps will cause this issue:
1. Using the ASP.NET 4 version of aspnet_regiis, run "aspnet_regiis -u"
2. Using the ASP.NET 4 version of aspnet_regiis, run "aspnet_regiis -i -enable"
To resolve this issue:
In the ASP.NET version list in the IIS MMC, manually select the version of ASP.NET that you want and then click "Apply".
Some ASP.NET compilation tasks on Windows Vista, Windows Server 2008, and Windows 7 might fail because the IIS worker process does not have write permissions to the Windows temporary directory (%WINDOWS%\Temp). When you try to compile items such as Web service references that depend on WSDL files, you might see errors such as "Parser Error Message: Unable to generate a temporary class."
This error occurs if IIS is enabled on the computer and the .NET Framework 4 is installed, but the ASP.NET and .NET Extensibility features have not been enabled.
To resolve this issue:
Option 1
----------
Explicitly grant write permissions to the Windows temporary directory (%WINDOWS%\Temp) for the IIS worker process account. To do this, grant write access to a group that includes the worker process account, for example, the IIS_IUSRS group.
Option 2
---------
Enable the ASP.NET and .NET Extensibility features. In Windows Control Panel, open "Programs", and under "Programs and Features", click "Turn Windows features on and off". In the "Windows Features" dialog box, open the "Internet Information Services" node, then "World Wide Web Services", and then "Application Development Features". Enable the following features:
.NET Extensibility
ASP.NET
You can precompile ASP.NET Web sites by using the aspnet_compiler.exe command-line tool. If you sign the resulting assemblies with a key, you can deploy assemblies in the GAC instead of the Web site's Bin folder.
In ASP.NET 4, if a Web site that is running in partial trust tries to load the assemblies from the GAC, a "System.Security.SecurityException" exception is thrown. This occurs because, by default, ASP.NET 4 uses a newer code access security (CAS) implementation than earlier versions of ASP.NET. In the new CAS implementation, precompiled and signed assemblies that are deployed in the GAC must be explicitly marked by using the "SecurityTransparent" attribute.
To resolve this issue:
Option 1
--------
Mark the assembly by using the "SecurityTransparent" attribute before you compile it, as shown in the following example:
[assembly:System.Security.SecurityTransparentAttribute]
Option 2
--------
Add a "compilerOptions" setting to the site's Web.config file, as described in the article "How to: Create Versioned Assemblies for Precompiled Web Sites" (http://msdn.microsoft.com/en-us/library/ms228042.aspx). As part of this process, add the following line to the AssemblyInfo.vb or AssemblyInfo.cs file that is referenced by the "compilerOptions" setting:
[assembly:System.Security.SecurityTransparentAttribute]
Option 3
--------
Create a dummy class library that contains the following attribute:
[assembly:System.Security.SecurityTransparentAttribute]
Compile the class library into an assembly, and then run the aspnet_merge.exe command-line tool on the precompiled Web site output by using the "copyattrs" option, as shown in the following example:
aspnet_merge c:\MyApplicationRootDirectory -copyattrs assemblyfile.dll
For the DLL name, use the name of the dummy class library that is marked with the "SecurityTransparent" attribute.
Option 4
--------
Temporarily revert to the older CAS mode by setting the "legacyCasModel" attribute of the "trust" element to "true" in the site's Web.config file, as shown in the following example:
<trust level="Medium" legacyCasModel="true"/>
After you have made this change, we recommend that you use one of the other options to add the "SecurityTransparent" attribute to precompiled assemblies. You can then remove the "legacyCasModel" attribute and run the Web site in the new CAS mode.
If new configuration sections are added to the application Web.config file of an ASP.NET or WCF application, the application will fail to start when it is running in IIS 7 Integrated mode.
For example, if a <standardEndpoints> configuration section is added to the Web.config file of a WCF application, the application will not start when it is running in IIS 7 Integrated mode. Instead, IIS 7 will return a configuration validation error, because the new configuration section is not recognized by the IIS 7 configuration system.
To resolve this issue:
You can download and install a publicly available hotfix for this issue. The hotfix is available at http://support.microsoft.com/kb/958854. Alternatively, you can install Windows Vista SP 2, which includes the fix.
ASP.NET 4 must be re-registered if IIS 7/7.5 or the IIS 7/7.5 .NET Extensibility feature is enabled after the .NET Framework 4 has been installed on the computer. ASP.NET 4 must also be re-registered if the .NET Extensibility feature is removed when the .NET Framework version 4 is installed on the computer.
For both cases, re-registration is required because the operating system installation and uninstallation processes for IIS 7 and IIS 7.5 and for the .NET Extensibility feature were not designed for the scenario where a later version of the .NET Framework already exists on the computer.
To resolve this issue:
To re-register ASP.NET 4, run the following command:
aspnet_regiis -iru -enable
Make sure that you use the version of aspnet_regiis.exe that is installed in the .NET Framework 4 installation directory.
If ASP.NET 1.1 is manually registered on Windows Server 2003, and then ASP.NET 4 is manually registered on the same instance of Windows Server 2003, global ASP.NET performance counters stop working. The following steps will reproduce the problem:
1. Make sure that the .NET Framework 1.1 and the .NET Framework 4 are both installed on a computer that is running Windows Server 2003.
2. Register ASP.NET 1.1 by using the following command:
aspnet_regiis /i /enable
3. Register ASP.NET 4.0 by using the following command:
aspnet_regiis /ir
4. Open the Perfmon application and add the following performance counter:
ASP.NET Application\Requests/sec
5. Request an .aspx page and then examine the value of the performance counter. The value will be zero.
To resolve this issue:
Before you install the .NET Framework 4 on a computer where the .NET Framework 1.1 is also installed, perform the following steps:
1. Make sure that IIS is already installed.
2. Make sure that ASP.NET 1.1 has been registered with IIS, and confirm that it is successfully processing .aspx pages.
The ASP.NET tab might not be displayed if you run the management console (MMC) on a local computer when you administer a remote Web server. This occurs when you use the IIS 6 management tool to remotely manage a Web server that has ASP.NET installed, and when the local computer is running Windows Server 2008 x64, Windows 7, or Windows Server 2008 R2 (either x86 or x64).
To resolve this issue:
There is no workaround.
Running the ASP.NET 2.0 version of the "aspnet_regiis -ua" command on Windows Vista, Windows Server 2008, Windows 7, or Windows Server 2008 R2 causes the following error:
The request is not supported.
This occurs because the ASP.NET 2.0 version of the "aspnet_regiis" command cannot detect that another version of ASP.NET exists on the computer.
To resolve this issue:
To unregister all versions of ASP.NET on the computer, run the ASP.NET 4 version of the "aspnet_regiis -ua" command.
For ASP.NET 2.0, the "aspnet_regiis -i" command recursively upgrades all virtual directories on Windows Server 2003 to use ASP.NET 2.0. For ASP.NET 4, the "aspnet_regiis -i" command on Windows Server 2003 upgrades only the root of IIS 6 to ASP.NET 4. If any virtual directories below the root are explicitly set to run a specific version of ASP.NET, those virtual directories retain the version of ASP.NET that was explicitly set instead of inheriting the ASP.NET 4 setting from the root directories.
To resolve this issue:
Run the ASP.NET 4 versions of either of the following commands:
aspnet_regiis -s
aspnet_regiis -r
These commands force a recursive update of all virtual directories to ASP.NET 4.
Unregistering ASP.NET 2.0 on any operating system version where ASP.NET 4 is already registered corrupts some performance counter registrations for ASP.NET 4. This occurs because the ASP.NET 2.0 unregistration process cannot detect that a later version of ASP.NET is installed on the computer. As a result, when you use certain ASP.NET 4 performance counters, errors such as the following one might appear in the application event log:
"Unable to locate the open procedure "%pef_counter_name%" in DLL "%WINDOWS%\Microsoft.NET\Framework\v4.0.NNNNN\aspnet_perf.dll" for the "ASP.NET" service."
"Performance counter data collection from the "ASP.NET" service has been disabled due to one or more errors generated by the performance counter library for that service."
To resolve this issue:
Run the ASP.NET 4 version of the "aspnet_regiis -iru" command. This re-registers the ASP.NET 4 performance counters.
By default, ASP.NET 4 Web projects and Web applications that rely on SQL Server Express user instances do not work under the following scenarios:
1. A Web application project (WAP) is hosted as a virtual directory on any version of IIS. This is because SQL Server Express user instances require specific file permissions for the user's Documents folder and the default IIS service account (NETWORK SERVICE) does not have these permissions.
2. A Web site is hosted on IIS 7.5 running on Windows 7 or on Windows Server 2008 R2. This is because the default security credentials for IIS 7.5 application pools are not based on NETWORK SERVICE.
To resolve this issue:
For details about how to address these issues, see the article at
http://go.microsoft.com/fwlink/?LinkID=160102
In ASP.NET 4, the default Web.config file has been substantially reduced in size. As a result, IIS 7 (on Windows Vista and on Windows Server 2008) and IIS 7.5 (on Windows Server 2008 R2) will throw configuration errors. The exact errors depend on the updates that have been installed on the operating system and on the kind of configuration information that is contained in application-level Web.config files.
Windows Vista SP1 or Windows Server 2008 SP1, where neither hotfix KB958854 nor SP2 are installed. In this configuration, the IIS 7 configuration system incorrectly merges an application's managed configuration by comparing the application-level Web.config file to the ASP.NET 2.0 machine.config files. Because of this, application-level Web.config files from the .NET Framework 3.5 or the .NET Framework 4 must have a <system.web.extensions> configuration section in order not to cause an IIS 7 validation failure. Manually modified application-level Web.config file entries that do not precisely match the original boilerplate configuration section definitions that were introduced with Visual Studio 2008 will cause configuration errors. (The default configuration entries that are generated by Visual Studio 2008 do work.) A common problem is that manually modified Web.config files leave out the configuration attributes for "allowDefinition" and "requirePermission" that are found on various configuration section definitions. As a result, there is a mismatch between the abbreviated configuration section in application-level Web.config files and the complete definintion in the ASP.NET 4 machine.config file. Therefore, at run time, the ASP.NET 4 configuration system throws a configuration error.
Windows Vista SP2, Windows Server 2008 SP2, Windows 7, Windows Server 2008 R2, and also Windows Vista SP1 and Windows Server 2008 SP1 where hotfix KB958854 is installed. In this scenario, the IIS 7 and IIS 7.5 native configuration system returns a configuration error because it performs a text comparison on the "type" attribute that is defined for a managed configuration section handler. Because all Web.config files that are generated by Visual Studio 2008 and Visual Studio 2008 SP1 have "3.5" in the type string for the <system.web.extensions> (and related) configuration sections, and because the ASP.NET 4 machine.config file has "4.0" in the "type" attribute for the same configuration sections, applications that are generated in Visual Studio 2008 or Visual Studio 2008 SP1 always fail configuration validation in IIS 7 and IIS 7.5.
To resolve this issue:
For the first scenario, update the application-level Web.config file by including the boilerplate configuration text from a Web.config file that was generated automatically by Visual Studio 2008.
For the second scenario, delete or comment out all the <system.web.extensions> configuration section definitions and configuration section group definitions from the application level Web.config file.
The System.Web.Hosting.IProcessHostPreloadClient.Preload method takes a string array as an input parameter. However, there is no way to set this data, and no information is ever passed in this parameter.
To resolve this issue:
Earlier versions of the IIS 7.5 autostart feature supported a way to configure one or more string values to pass to the ASP.NET 4 IProcessHostPerloadClient.Preload method. However, that functionality was removed before the release of Windows 7 and of Windows Server 2008 R2.
The IIS 7 and IIS 7.5 .NET Extensibility feature is a configuration option that is available in the "Windows Features" dialog box to install or uninstall IIS 7 or IIS 7.5 features. The feature is located in the following node:
Internet Information Services > World Wide Web Services > Application Development Features > .NET Extensibility
On Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2, the .NET Extensibility feature affects only ASP.NET 2.0 integration with IIS 7 or IIS 7.5. It has no effect on registering or unregistering ASP.NET 4 with IIS 7 or IIS 7.5.
To resolve this issue:
To manage ASP.NET 4 integration with IIS 7 or IIS 7.5, use the ASP.NET 4 version of the "aspnet_regiis.exe" command.
On 64-bit computers that are running both ASP.NET 2.0 and ASP.NET 4, some installation sequences can render the ASP.NET 2.0 version of the "aspnet_regiis -ga" command inoperable. This is because the ASP.NET 4 version of "aspnet_regiis" tries to clean up unused ASP.NET 2.0 registry keys and in the process, it deletes registry keys that are required for ASP.NET 2.0.
To resolve this issue:
Rerun the "aspnet_regiis" command. Follow these guidelines:
1. Run the 32-bit version of the ASP.NET 2.0 "aspnet_regiis -iru" command. This is always required because the 32-bit version creates some registry keys that are shared with the 64-bit version.
2. If you are running 64-bit ASP.NET 2.0 applications, also run the 64-bit 2.0 version of the "aspnet_regiis - iru" command.
3. Re-register ASP.NET 4 by using the ASP.NET 4 versions of the "aspnet_regiis -iru" command (both 32-bit and 64-bit).
In ASP.NET 4 Beta 2, to reduce the size of the Web.config file that each ASP.NET application requires, a number of assembly references, control references, and module and handler declarations were moved from the application-level Web.config file into the machine-level Web.config file. This might impact existing ASP.NET 3.5 SP1 (and earlier) applications if the following conditions are both true:
· The application-level Web.config file contains entries that have been moved to the root Web.config file.
· You run the application in an application pool that is targeting ASP.NET 4.
If the conditions are true, then running the application might cause an error that lists configuration entries that are defined multiple times.
To resolve this issue:
Remove duplicate entries from the application-level Web.config file.
The ClientIDMode property is introduced in ASP.NET 4. This property enables the size of the rendered id attribute for ASP.NET controls to be reduced. Controls for which no ID property is set will not have an auto-generated ClientID value created for them (for example, ctl_001).
The lack of an ID in this case can impact third-party controls that rely on an auto-generated ID to function correctly, for example, when they use client- side scripting. In these cases, the Control.ClientID property does not return the correct value.
To resolve this issue:
If the application uses controls that are affected by this issue, revert the application to the ASP.NET 3.5 SP1 client ID behavior by making the following setting in the application-level Web.config file:
<system.web>
<pages clientIDMode="AutoID" />
</system.web>
ASP.NET 2.0 applications that run on IIS 6 (in either Windows Server 2003 or Windows Server 2003 R2) might generate errors such as this one:
System.Web.HttpException: Path '/[yourApplicationRoot]/eurl.axd/[Value]' was not found.
This error occurs only after ASP.NET 4 has been enabled on IIS 6. This error occurs because when ASP.NET detects that a Web site is configured to use ASP.NET 4, a native component of ASP.NET 4 passes extensionless URLs to the managed portion of ASP.NET for further processing.
However, if virtual directories that are below an ASP.NET 4 Web site are configured to use ASP.NET 2.0, processing the extensionless URL in this way causes a modified URL that contains "eurl.axd", which is then sent to the ASP.NET 2.0 application. ASP.NET 2.0 cannot recognize the "eurl.axd" format. Therefore, ASP.NET 2.0 tries to find a file named "eurl.axd" and execute it. Because no such file exists, the request fails with an "HttpException" exception.
To resolve this issue:
Option 1
--------
If ASP.NET 4 is not required in order to run the Web site, remap the site to use ASP.NET 2.0 instead.
Option 2
---------
If ASP.NET 4 is required in order to run the Web site, move any child ASP.NET 2.0 virtual directories to a different Web site that is mapped to ASP.NET 2.0.
Option 3
---------
If it is not practical to remap the Web site to ASP.NET 2.0 or to change the location of a virtual directory, explicitly disable extensionless URL processing in ASP.NET 4 by following these steps:
1. In the Windows registry, open the following node:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.<build#>
Note: Because the .NET 4 Framework has not yet been released, a fixed build number was not available when these instructions were written. For <build#>, substitute the build number of the actual release when it is available.
2. Create a DWORD value named "EnableExtensionlessUrls".
3. Set "EnableExtensionlessUrls" to 0. This disables extensionless URL behavior.
4. Save the registry value and close the registry editor.
5. Run the "iisreset" command-line tool, which causes IIS to read the new registry value.
Note: Setting "EnableExtensionlessUrls" to 1 enables extensionless URL behavior. This is the default setting if no value is specified.
The browser definition files have been updated to contain information about new and updated browsers and devices. Older browsers and devices such as Netscape Navigator have been removed, and newer browsers and devices such as Google Chrome and Apple iPhone have been added.
To resolve this issue:
You can use the old browser definition files with ASP.NET 4. For more information, see the ASP.NET 4 and Visual Studio 2010 Web Development Overview white paper, which is available at http://www.asp.net/learn/whitepapers/aspnet40/.
The latest version of the ASP.NET Ajax Library is not included in ASP.NET 4. Features of the ASP.NET Ajax Library, for example, client templates, client controls, client data access, and the client script loader, are not included in the version of the ASP.NET Ajax Library that is included in ASP.NET 4.
To resolve this issue:
You can download the ASP.NET Ajax Library separately from ASP.NET. For more information, see the ASP.NET 4 and Visual Studio 2010 Web Development Overview white paper, which is available at http://www.asp.net/learn/whitepapers/aspnet40/.
In earlier versions of ASP.NET, a reference to the System.Web.Mobile.dll assembly was included in the root Web.config file in the <assemblies> section under <system.web><compilation>. To improve performance, the reference to this assembly has been removed.
To resolve this issue:
The System.Web.Mobile.dll assembly is included in ASP.NET 4, but it is deprecated. If you want to use types from the System.Web.Mobile.dll assembly, add a reference to this assembly either in the root Web.config file or in an application Web.config file. For example, if you want to use any of the (deprecated) ASP.NET mobile controls, you must add a reference in the Web.config file to the System.Web.Mobile.dll assembly.
There are no known issues.
There are no known issues.
There are no known issues.
There are no known issues.
There are no known issues.
There are no known issues.
There are no known issues.
There are no known issues.
There are no known issues.
© 2010 Microsoft Corporation. All rights reserved.