For the most current version of the Beta 2 Readme, click here.
The most current version of the Beta 1 Readme is available here.
1.2 Supported Operating Systems:
1.4 Other System Requirements:
If the .NET Framework 4 Beta 1 is installed when you try to install the .NET Framework 4 Beta 2, applications that target the .NET Framework will not function correctly.
To resolve this issue:
See the Beta 2 Installation Readme Addendum for step-by-step instructions about how to avoid this situation, and and also about how to rectify it.
The Beta 2 Installation Readme Addendum is available here.
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 files for Visual Basic (vbc.rsp) and C# (csc.rsp) contain 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. For Beta 2, these response files have been pared down to the set of references that are available in both the full version of the .NET Framework 4 and the .NET Framework 4 Client Profile. This means that when you use vbc.exe or csc.exe on the command line, you may have to specify any other references explicitly.
This issue does not affect builds in Visual Studio 2010, nor builds in MSBuild, because those methods of building already require project references to be specified explicitly.
Note: The contents of the response files may change again for the release version.
To resolve this issue:
Explicitly specify any required references as command-line arguments to vbc.exe or csc.exe.
The estimated download size and time are blank when the Web installer is used.
To resolve this issue:
No workaround is required. The Web installer downloads only the components that are required for your computer.
The approximate sizes that the Web installer will download are as follows:
x86: about 40 MB
x64: about 60 MB
The .NET Framework 4 download sometimes fails to extract on systems where the majority of free space is on a drive that is not accessible from Windows. This is mostly noticed on MacBooks on which Windows runs in an emulation, or on dual-boot PCs that have Linux or another operating system on an another partition. This issue applies to all .NET Framework 4 profiles.
To resolve this issue:
Log into your system as administrator.
In the Control Panel, open Administrative Tools, then Computer Management, then Storage.
Select the Drive that contains the Mac or Linux partition. Select "Change Drive Letter and Path".
Click Remove. You can ignore the warning about programs not working with the drive letter removed because you will be restoring it after the .NET Framework Setup finishes. Remove the drive letter.
Minimize the Computer Management window.
Install the .NET Framework.
Display the Computer Management window.
Select the Drive that contains the Mac or Linux partition. Select "Change Drive Letter and Path".
Restore the drive letter.
If the .NET Framework 4 Beta 1 is installed when you try to install the .NET Framework 4 Beta 2, applications that target the .NET Framework will not function correctly.
To resolve this issue:
See the Beta 2 Installation Readme Addendum for step-by-step instructions about how to avoid this situation, and and also about how to rectify it.
The Beta 2 Installation Readme Addendum is available here.
On touch-enabled computers (for example, Tablet), when you upgrade from the .NET Framework 4 Beta 1 to the Beta 2, existing .NET Framework 3.x applications may crash. .NET Framework 3.x applications may also crash after the .NET Framework 4 Beta 1 is uninstalled on touch-enabled computers.
To resolve this issue:
1. Open an administrator Command Prompt window.
2. Change directory to each location where penIMC.dll 3.0 is located. Typically, these locations are:
· C:\Windows\Microsoft.NET\Framework\v3.0\WPF
· C:\Windows\Microsoft.NET\Framework64\v3.0\WPF
3. Run the following command:
regsvr32 PenIMC.dll
The estimated download size and time are blank when the Web installer is used.
To resolve this issue:
No workaround is required. The Web installer downloads only the components that are required for your computer.
The approximate sizes that the Web installer will download are as follows:
x86: about 30 MB
x64: about 50 MB
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.
To uninstall the Full Framework, you must uninstall the following items in the specified order:
To resolve this issue:
There is no workaround.
After removing .Net Framework 4.0, the Workflow debugger does not work.
To resolve this issue:
Repair current .Net Framework version using Control Panel.
There are no known issues.
Because of late-breaking changes to the Managed Location API in the System.Device.Location namespace, which could not be included in Beta 2, the Location API should be considered preliminary and subject to change between Beta 2 and the final release of the .NET Framework 4.
To resolve this issue:
There is no workaround. Code that targets the Managed Location API must be rewritten to reflect any changes in the final release of the Framework.
To eliminate related build errors, delete references to specific versions of the .NET Framework in the Visual Basic project templates.
To resolve this issue:
Open the Project Templates. (Typically located in ..\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\ProjectTemplates\VisualBasic\Workflow\1033\.)
Unzip the project template zip files. For example, ActivitiyLibrary.zip.
Open ActivityLibrary.vbproj in Notepad.
In the ItemGroup References, delete all the Version-specific data. For example, instead of:
<Reference Include="System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
use:
<Reference Include="System" />
- Do this for all the references in the .vbproj files.
- When you are finished,&nbs- When you are finished, zip the file again. Also replace the file in ..\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\ProjectTemplatesCache\VisualBasic\Workflow\1033\
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 IIS7/7.5 .NET Extensibility feature is enabled after the .NET Framework 4 has already 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 process for IIS7 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 version 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, do the following:
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 results in 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 a later version of ASP.NET exists on the computer.
To resolve this issue:
Run the ASP.NET 4 version of the "aspnet_regiis -ua" command to unregister all versions of ASP.NET on the computer.
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 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 later 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. As a result, 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:
The workaround for the first scenario is to 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.
The workaround for the second scenario is to 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 preview 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 final 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:
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>
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 Beta 2 Overview white paper, which is available at http://www.asp.net/learn/whitepapers/aspnet40/.
The latest version of the Microsoft Ajax Library is not included with ASP.NET 4. Features of the Microsoft Ajax Library such as client templates, client controls, client data access, and the client script loader will not be included with the version of the Microsoft Ajax Library that is included with ASP.NET 4.
To resolve this issue:
You can download the Microsoft Ajax Library separately from ASP.NET. For more information, see the ASP.NET 4 and Visual Studio 2010 Web Development Beta 2 Overview white paper, which is available at http://www.asp.net/learn/whitepapers/aspnet40/.
Users may encounter configuration errors when they attempt to use ASP.NET administration modules in the IIS Manager tool on Windows Server 2008 x64. The reason is that the NetFx40_IIS_schema_update.xml schema file is not being copied into the IIS configuration schema directory. As a result, when the IIS Manager tool reads unrecognized elements and attributes it throws a configuration exception.
To resolve this issue:
1. Go the CONFIG subdirectory of the .NET Framework installation directory. This directory is located on a path that resembles %driveroot%\Windows\Microsoft.NET\Framework\v4.0.20916\Config
2. Copy the NetFx40_IIS_schema_update.xml from the CONFIG subdirectory to the IIS configuration schema directory. The IIS configuration schema directory is located on a path that resembles:
%driveroot%\Windows\System32\inetsrv\config\schema
If web.config contains the system.web/pages/clientIdMode attribute (<pages clientIdMode="Inherit|AutoID|Predictable|Static" />), the IIS Manager will throw configuration exceptions on Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2. This occurs because the Beta 2 version of NetFx40_IIS_schema_update.xml does not include a definition for the new clientIdMode attribute.
To resolve this issue:
1. Navigate to the IIS configuration schema directory. The IIS configuration schema directory is located on a path that resembles %driveroot%\Windows\System32\inetsrv\config\schema.
2. Open the file NetFx40_IIS_schema_update.xml in a text editor and find the XML element <sectionSchema name="system.web/pages">
3. Add a sub-element under the sectionSchema that defines the clientIdMode attribute: <attribute name="clientIdMode" type="string" />
4. Save the file.
In ASP.NET 4 Beta 1, a property named ht: normal">RenderTable was added to the FormView control. This property lets you disable the control from rendering an HTML table element around the contents of the control. In Beta 2, the property has been renamed to RenderOuterTable.
To resolve this issue:
Change any instances of markup that resemble this:
<asp:FormView RenderTable="false">
To this:
<asp:FormView RenderOuterTable="false">
To enable Visual Studio 2010 Beta 2 to identify which version of the .NET Framework to target for an ASP.NET Web project, the application Web.config file of the project contains a property that specifies the target version. This value is set in the opening <compilation> tag by using syntax that resembles this:
<compilation targetFramework="4.0" />
In earlier Beta releases of ASP.NET 4, this property was named targetFrameworkVersion. It was renamed targetFramework for the Beta 2 release.
To resolve this issue:
If you created projects in earlier versions of ASP.NET 4, and if the projects include the targetFrameworkVersion attribute in the compilation element of the application Web.config file, change the name of the attribute to targetFramework.
Note: For more information about multi-targeting in ASP.NET Web applications, see ASP.NET 4.0 and Visual Studio 2010 Web Development Beta 2 Overview on the ASP.NET Web site.
When the .NET Framework 4 Beta 2 is installed and ASP.NET 4 is enabled in IIS, a required file is not copied to the correct location. As a result, when you try to open the property pages for some IIS components (for example, .NET Compilation), an error occurs in IIS Manager.
To resolve this issue:
Copy the NetFX40_IIS_schema_update.xml file in:
%WINDIR%\Microsoft.NET\Framework\v4.0.xxx\Config\
And then paste it in:
%WINDIR%\System32\inetsrv\config\schema\
The "xxx" in the source path represents the exact version of the .NET Framework 4 Beta 2 that you have installed.
There are no known issues.
There are no known issues.
There are no known issues.
In the .NET Framework 4, the Entity Framework supports entities with persistence ignorance. When these entities are used, the ObjectContext can be configured to optionally create and use dynamically generated proxies to enable lazy loading and automatic change detection. Dynamic proxies cannot be serialized by using any of the default WCF DataContract serialzers. To use dynamic proxies with WCF services, DataContractResolvers enable the serialization process to convert the dynamic proxy type to the base entity type, which can be serialized and deserialized. The Entity Framework includes a ProxyDataContractResolver that performs the conversion between dynamic proxies and the base entity types. ProxyDataContractResolver can be used in OperationBehavior implementations or passed as a delegate to the new DataContractSerializer contructor that accepts a resolver delegate. However, the ProxyDataContractResolver does not work with generic collection types such as ICollection<T> or List<T> in Beta 2.
When the ProxyDataContractResolver is used with generic collections in the .NET Framework 4 Beta 2, a CommunicationException is thrown from the service call together with the message that "The deserializer has no knowledge of any type that maps to this name. Consider changing the implementation of the ResolveName method on your DataContractResolver to return a non-null value for name 'ArrayOf[Type]'"¦". This issue will be addressed for the final release of the .NET Framework 4.
To resolve this issue:
No work-around is available for serializing a dynamic proxy that contains a generic collection.
To prevent the ObjectContext from creating and using dynamic proxies for entities with persistence ignorance, set the ObjectContext.ContextOptions.ProxyCreationEnabled flag to 'false'.
When a WCF client application is hosted in partial trust (for example XBAP, middle-tier service), every asynchronous call, except the first call, to an Https client proxy will fail with a SecurityException.
To resolve this issue:
1) Use the synchronous client proxy APIs.
2) Close the proxy between every asynchronous call.
3) Make the call over Http instead of Https.
When a new WCF WF service item is added to an existing project, the build will fail because the new item is added with an incorrect build action.
To resolve this issue:
Change the build action of the new item to Content.
XamlBuildTask fails on ia64 because Microsoft.WinFx.targets are not present on that architecture.
To resolve this issue:
No workaround is available.
A project that has a XAML file that contains validation errors will throw an error on the first build attempt, but will not throw an error on a second build attempt. The project will then fail at runtime.
To resolve this issue:
Use Rebuild after a XAML validation error, instead of Build.
There are no known issues.
When you open a workflow code file in its Primary logical view (for example, by using VsShellUtilities.OpenDocument()), the code file opens instead of the designer. If the workflow code file is then opened in the Designer logical view (for example, by double-clicking the file in Solution Explorer), the designer will open in a broken state and will display an error message about missing services.
To resolve this issue:
In Visual Studio 2010, binding a HandleExternalEventActivity event property 'e' to another activity's property as a new member (Create Field Type) produces the following incorrect code:
Public ee As System.Workflow.Activities.ExternalDataEventArgs = New System.Workflow.Activities.ExternalDataEventArgs
This produces the following error message:
Overload resolution failed because no accessiblie 'New' accepts this number of arguments.
To resolve this issue:
Change this generated code:
Public ee As System.Workflow.Activities.ExternalDataEventArgs = Nothing
To this code:
Public ee As System.Workflow.Activities.ExternalDataEventArgs = New System.Workflow.Activities.ExternalDataEventArgs
If a workflow that is created in Visual Basic has the Root Namespace property set, and if the workflow is created in a Microsoft.* namespace, the project will create errors when it is built.
To resolve this issue:
Avoid using the Microsoft.* namespace for these workflows. If this is not possible, avoid setting the Root Namespace property for the project.
There are no known issues.
© 2009 Microsoft Corporation. All rights reserved.