The Microsoft .NET Framework 4 Beta 1 cannot be installed if the .NET Framework 1.0 is already installed.
To resolve this issue:
1) In the program installation section of the Windows Control Panel, uninstall the .NET Framework 1.0.
2) Install the .NET Framework 4 Beta 1.
Note: You cannot install the .NET Framework 4 Beta 1 on operating systems that have the .NET Framework 1.0 built in.
After the 4 Framework is installed, if the computer is not rebooted, the IIS w3svc World Wide Web Publishing Service will not be started.
To resolve this issue:
Either manually restart the w3svc service, or reboot the computer so that w3svc will automatically start when the computer restarts.
There are no known issues.
There are no known issues.
There are no known issues.
The .NET Framework 4 is compatible with earlier versions of the .NET Framework (2.0 through 3.5 SP1), and most applications and components built against earlier versions of the Framework will run on Framework version 4. However, some changes in the .NET Framework 4 could impact applications and components.
To resolve this issue:
1) Visit the .NET Framework Compatibility blog (http://go.microsoft.com/fwlink/?LinkID=150906&clcid=0x409) for the latest information about known migration issues in Beta 1 and instructions about how to test your applications and components.
2) Please test your applications and components, and use Microsoft Connect to file any issues you find.
Do not take a dependency on class System.Collections.Concurrent.ConcurrentLinkedList<T> because it will be removed in later releases.
To resolve this issue:
There's no workaround available.
The System.Collections.Concurrent.ConcurrentQueue<T>.TryRemove method may hang if the value of the collection parameter of the constructor is a multiple of 32.
To resolve this issue:
When you instantiate the object, avoid setting the collection parameter to a multiple of 32.
There is a potential race condition on the System.Threading.Tasks.TaskCompletionSource<TResult> object. If the TaskCompletionSource<TResult>.TrySetResult method is called at the same time as Task<TResult>.Result, the Result may be incorrect.
To resolve this issue:
There's no workaround available.
Do not take a dependency on class System.LazyVariable<T>, because will be removed in later releases.
To resolve this issue:
Use the System.Lazy<T> class instead.
If an ASP.NET or WCF application adds new configuration sections to the application Web.config file, the application will fail to start when it is running in IIS7 integrated mode.
For example, if a WCF application adds the new <standardEndpoints /> configuration section to an application Web.config file, the WCF application will not start when it is running in IIS7 integrated mode. Instead, IIS7 will return a configuration validation error because the new configuration section is not recognized by the IIS7 configuration system.
To resolve this issue:
Download and install a publicly available hotfix for this issue. The hotfix is available at: http://support.microsoft.com/kb/958854.
Alternatively, when Windows Vista SP2 becomes available, you can install it because it includes the required fixes.
If ASP.NET 1.1 is manually registered on Windows Server 2003, and then ASP.NET 4.0 is manually registered on Windows Server 2003, global ASP.NET performance counters stop working.
Example steps to reproduce the problem:
1. Install ASP.NET 1.1 by using the following command line: aspnet_regiis /i /enable
2. Install ASP.NET 4.0 by using the following command line: aspnet_regiis /ir
3. Open "Perfmon" and add the performance counter "ASP.NET Application\Requests/sec"
4. Request an .aspx page and look at the value of the performance counter.
The performance counter will return a value of zero.
To resolve this issue:
Before you install the the .NET Framework 4 on a computer where the the .NET Framework 1.1 is also required, ensure that:
1. IIS is installed on the computer.
2. ASP.NET 1.1 has been registered with IIS and confirmed to be serving pages.
Manually un-registering ASP.NET 4.0 on Windows Server 2008 after un-registering ASP.NET 2.0 will cause an uninstall error about performance counters in the ASP.NET Setup log. The error will resemble the following:
"The description for Event ID 1073 from source ASP.NET 4.0.20xxx.0 cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.
If the event originated on another computer, the display information had to be saved with the event."
This problem can occur if the following comands are run:
1. aspnet_regiis -u [run the version in the .NET Framework 2.0 installation directory]
2. aspnet_regiis -u [run the version in the .NET Framework 4 installation directory]
To resolve this issue:
Ensure that ASP.NET 2.0 is still registered with IIS7 on Windows Server 2008 before you un-register ASP.NET 4.0. Based on the steps from the problem statement, this means that you should run the 4.0 version of aspnet_regiis -u before you run the 2.0 version of aspnet_regiis -u.
ASP.NET 1.1 can no longer be selected on the ASP.NET MMC tab on Windows Srver 2003 after aspnet_regiis -ua is run, and then both ASP.NET 1.1 and ASP.NET 4.0 are subsequently re-registered.
The following steps will cause this issue:
1. Start with a Windows Server 2003 computer that has both ASP.NET 1.1 and ASP.NET 4.0 registered.
2. Run aspnet_regiis -ua (either version of aspnet_regiis will work).
3. Manually re-register ASP.NET 1.1 by using aspnet_regiis -i /enable.
4. Manually re-register ASP.NET 4.0 by using aspnet_regiis -i /enable.
In the IIS MMC, the ASP.NET tab will no longer let you set ASP.NET 1.1 as the selected version for a Web site or Web application.
To resolve this issue:
Do not use aspnet_regiis -ua to uninstall versions of ASP.NET. Instead, manually uninstall ASP.NET 4.0 (by using aspnet_regiis -u) before you uninstall ASP.NET 1.1.
If the computer is in the state where ASP.NET 1.1 can no longer be selected on the MMC tab, you must use the command-line asnet_regiis tool from the .NET Framework 1.1 installation directory to explicitly associate it with a Web site or Web application.
After either unregistering ASP.NET 4.0 by using "aspnet_regiis -u" or uninstalling the .NET Framework 4 on Windows Vista or Windows Server 2008, ASP.NET ETW trace events are no longer available because the un-registration process for ASP.NET 4.0 fails to re-register the 2.0 ETW trace events.
To resolve this issue:
Re-register ASP.NET 2.0 on Windows Vista or Windows Server 2008 by using "aspnet_regiis -i".
Alternatively, by using the "Turn Windows Features On or Off" option in the "Program and Features" section of the Control Panel, you can disable and then re-enable "Application Development Features --> .NET Extensibility" and "Application Develoment Features --> ASP.NET" under the "Internet Information Services --> World Wide Web Services" feature.
If you manually migrate an existing application to the .NET Framework 4, or if you try to use the ASP.NET 4.0 compiler to compile an application that was created by using an earlier version of ASP.NET, the application will not run if the its Web.config file does not contain a section that indicates the target Framework (together with the corresponding codeDOM sections). For example, this might occur if you migrate your application manually by re-mapping the IIS application pool for the application to the .NET Framework 4 without making the required changes in the Web.config file.
To resolve this issue:
Open the existing ASP.NET application in Visual Studio 2010 (by using the .NET Framework 4). Visual Studio will prompt you to upgrade (migrate) your application. During the upgrade, Visual Studio adds the required entries to the application Web.config file to specify the target version of the .NET Framework.
ASP.NET 4.0 must be re-registered if either IIS7, or the IIS7 .NET Extensibility feature, is enabled after the .NET Framework 4 is installed on the computer.
ASP.NET 4.0 also must be re-registered if the .NET Extensibility feature is removed when the .NET Framework 4 is already installed on the computer.
For both cases, re-registration is required because the operating system install/uninstall logic for both IIS7 and the .NET Extensibility feature was not designed for the scenario where a higher version of the .NET Framework already exists on the computer.
To resolve this issue:
To re-register ASP.NET 4.0, run the following command: "aspnet_regiis -iru -enable".
Make sure to use the version of aspnet_regiis.exe that is installed in the .NET Framework 4 installation directory.
When you try to add the assembly for the Ajax Control Toolkit (1.0 or later) to the Toolbox in Visual Studio 2010 Beta 1 (by using the Choose Toolbox Items dialog box), Visual Studio throws a security exception because, by default, any third-party assembly (including AjaxControlToolkit.dll) is marked as untrusted when it is downloaded from the Web as a .dll or downloaded as a .zip file and then extracted.
To resolve this issue:
To work around this problem, mark the assembly as trusted for Visual Studio 2010 Beta 1. Follow these steps:
1. In Windows Explorer, right-click the AjaxControlToolkit.dll file, and then click Properties.
2. Click Unblock to set the file as trusted.
You can now add the AjaxControlToolkit assembly to the Toolbox.
If an application runs under Medium trust and uses Web Forms routing, an error occurs. Web Forms routing currently does not function correctly when an application is configured to run in Medium trust.
To resolve this issue:
Run your application under Full trust.
If you create a route URL in which a URL-encoded space is the final element (for example, http://localhost/mysite/category%20), URL routing will not function correctly. (URL encoding is performed automatically on the URL.)
To resolve this issue:
Make sure that there are no spaces at the end of a URL that uses routing.
Click your Form on the designer surface and press F4 to start the Properties window. The (Name) property of that Form cannot be found in its properties list because Name is a cached extender property and there is a bug that causes updates to the IExtenderListService not to be detected. The Form is reflected on before the NameExtenderProvider is registered, but controls are reflected on after, which enables them to still have the (Name) property. The missing (Name) property prevents users from viewing or changing the class name of the Form by using the PropertyGrid.
To resolve this issue:
There is no workaround to this problem. The (Name) property is used to customize the class name for the targeted Form. For example, the default class name for Form1 is - public class Form1 : Form. If the (Name) property of the Form is changed to ABC, then the class name should be automatically changed to ABC. It becomes - public class ABC : Form. In the case that you cannot find the (Name) property in form's properties list, you have to manually update the class name of targeted form (to one that best fits your code naming guidelines) in all related source code files (for example, Form1.cs, Form1.vb, Form1.Designer.cs, Form1.Designer.vb, and so on).
When you create a Windows Forms application that targets .NET Framework versions 2.0, 3.x, or 4, and then add a WPF UserControl project to the same solution and build it, you may encounter an error message when you add that WPF UserControl to the Form designer. The error message says: "Type 'WindowsFormsIntegration.Design.HostedComponent' is not available in the target framework". You might encounter the same issue when you add an ElementHost control to the Form designer, and then select the WPF UserControl in the SmartTag and build it.
To resolve this issue:
Add <vs install dir>\common7\ide\windowsformsintegration.Design.dll to project references and keep it referenced for as long as you have to use the WPF-WinForms interop designer.
There are no known issues.
There are no known issues.
The EntityDataSource control does not work in ASP.NET Partial Trust when the properties DefaultConatinerName and ConnectionString are set.
The page will throw an exception that resembles this:
[SecurityException]: Request for the permission of type 'System.Security.Permissions.FileIOPermission, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.
Cause:
There are two ways to initialize EntityDataSource control in an ASP.NET Page:
1. By setting DefaultContainerName and ConnectionString properties.
2. By setting ContextTypeName and (optionally) ConnectionString properties.
The first method is how the EntityDataSource Designer always initializes the control. The second method is used by ASP.NET Dynamic Data when scaffolding, and can also be used by configuring the control manually on the source view of the page.
When the first method is used (setting DefaultContainerName and ConnectionString), the EntityDataSource tries to load Entity Framework object mapping information from all assemblies that are referenced by the Web site or Web application. To optimize this process, the loading logic filters out assemblies that are signed by using the Microsoft public key.
To filter out those assemblies, the EntityDataSource invokes System.Reflection.Assembly.GetName(), which requires FileIOPermission. This permission is not available in Partial Trust on files that are outside the application directory. Because applications reference assemblies that are outside the application directory (for example, system assemblies are typically in the GAC), the aforementioned exception is thrown.
To resolve this issue:
Change the initialization of the EntityDataSource in either markup or code-behind to use ContextTypeName instead of DefaultContainerName. That way, the EntityDataSource will not try to load object metadata from additional assemblies:
1. In Visual Studio, switch the ASP.NET page that contains the EntityDataSource to “Source†view to modify the markup directly.
2. In the <asp:EntityDataSource /> tag, remove the attribute for DefaultContainerName.
3. Also in the <asp:EntityDataSource /> tag, add a ContextTypeName attribute that has a value equal to the type name of the derived ObjectContext that references the Entity types to be used.
For example:
<asp:EntityDataSource ID="EntityDataSource1" runat="server"
ConnectionString="name=NorthwindEntities"
DefaultContainerName="NorthwindEntities"
EntitySetName="Customers">
</asp:EntityDataSource>
Is changed to:
<asp:EntityDataSource ID="EntityDataSource1" runat="server"
ConnectionString="name=NorthwindEntities"
ContextTypeName="NorthwindEntities"
EntitySetName="Customers">
</asp:EntityDataSource>
There are no known issues.
The WCF samples hosted in IIS that are included in the .NET Framework 3.x do not run on the .NET Framework 4.
To resolve this issue:
1. In Solution Explorer, right-click the Project and then click Properties.
2. In the Application section, by using the Target Framework drop-down list, re-target the Project to the .NET Framework 3.0, 3.5, or 4, as appropriate for your scenario.
There are no known issues.
When using the InvokeMethod activity, you cannot pass the TargetObject argument at runtime through WorkflowInstance or WorkflowInvoker.
To resolve this issue:
Set the TargetObject argument at design time (in the designer).
To use the InvokePowerShell activity, follow these steps:
1. Install Windows PowerShell (unless you have Windows 7, which includes PowerShell v2). This provides:
a. Run-time engine for executing PowerShell commands.
b. API (encapsulated in System.Management.Automation.dll).
2. Add a reference to System.Activities.Extended.dll and System.Management.Automation.dll.
To resolve this issue:
None
The workflow samples that are included in the .NET Framework 3.x do not run on the .NET Framework 4.
To resolve this issue:
1. In Solution Explorer, right-click the Project and then click Properties.
2. In the Application section, by using the Target Framework drop-down list, re-target the Project to the .NET Framework 3.0, 3.5, or 4, as appropriate for your scenario.
There are no known issues.
© 2009 Microsoft Corporation. All rights reserved.