Microsoft .NET Framework 3.5 Service Pack 1 Beta Readme

1. System Requirements

1.1. Supported Architectures

  • x86
  • x64
  • ia64 (Windows Server 2008)

    1.2. Supported Operating Systems

  • Microsoft Windows XP
  • Microsoft Windows Server 2003
  • Windows Vista
  • Windows Server 2008

    1.3. Hardware Requirements

  • 620 MB of space on the system drive
        Note: You can use the Disk Cleanup utility available in Start -> Programs -> Accessories -> System Tools to remove temporary files.  
  • Minimum: 400 MHz CPU, 800x600 256-color display
  • Recommended:  1.0 GHz or higher CPU, 1024x768 high-color 32-bit display

    • 2. Known Issues

    2.1. Installing

    2.1.1. "Installer encountered an error: 0x8007177f. This machine is disabled for file encryption"

    Users receive an error message when they try to install an update on a Windows Vista computer in a domain. In the error log, the message is either "Error code 6015 for this component" or "Installer encountered an error: 0x8007177f. This machine is disabled for file encryption".

    To resolve this issue:

    Apply the update, which is available at http://support.microsoft.com/kb/933595.

    2.1.2. Installation fails if the Print Spooler Service is not running

    The installation of the XPSEPSC component requires that the Print Spooler Service be running in the 'Started' state.  If the Print Spooler Service is not running, the XPSEPSC installer will fail.  p>

    To resolve this issue:

    Start the Print Spooler service before you install .NET Framework. To do this:

    1. Click Start, point to Settings, click Control Panel, and then double-click Administrative Tools.

    2. Double-click Services, select Services (Local), right-click Print Spooler, and then click Properties.

    3. Click Start, and then click OK.

    2.1.3. ASP.NET 3.5 Extensions Preview is incompatible with .NET Framework 3.5 SP1

    If a computer has the December 2007 release of the ASP.NET 3.5 Extensions Preview installed, some ASP.NET applications will fail to run when .NET Framework 3.5 SP1 is installed.

    To resolve this issue:

    Uninstall the December 2007 ASP.NET 3.5 Extensions Preview before you install .NET Framework 3.5 SP1.

    2.1.4. Some components of .NET Framework 3.5 SP1 Beta will not be present on the computer after an operating system upgrade from Windows XP or Windows Server 2003 to Windows Vista

    Some components of .NET Framework 3.5 SP1 Beta will not be present on the computer after an operating system upgrade from Windows XP or Windows Server 2003 to Windows Vista.

    To resolve this issue:

    1. Open Add or Remove Programs.
    2. Uninstall .NET Framework 3.5 SP1 Beta.
    3. Reinstall .NET Framework 3.5 SP1 Beta from http://go.microsoft.com/fwlink/?LinkId=115068

    2.1.5. .NET Framework 2.0 SP2 Setup fails on Windows 2000 SP4 with the message "The procedure entry point HeapSetInformation could not be located in the dynamic link library KERNEL32.dll."

    .NET Framework 2.0 SP2 Setup fails on Windows 2000 SP4 with the message "The procedure entry point HeapSetInformation could not be located in the dynamic link library KERNEL32.dll."

    To resolve this issue:

    Install KB835732 from http://go.microsoft.com/fwlink/?LinkID=104408&clcid=0x409

    2.1.6. During .NET Framework installation or uninstallation, a message asks you to close the setup process

    During installation or uninstallation of .NET Framework 3.5 SP1 Beta, .NET Framework 3.0 SP2 Beta, and .NET Framework 2.0 SP2 Beta, this message appears: "The following application should be closed before continuing with setup:"
    The list of applications shown contains the Setup itself, and resembles this:
    Microsoft .NET Framework 3.5 SP1 (Beta) Setup

    To resolve this issue:

    Click "Ignore" and continue with Setup.

    2.1.7. Microsoft .NET Framework 3.5 SP1 Beta is not installed if Microsoft .NET Framework 3.5 Client Beta 1 is already installed on the computer

    Microsoft .NET Framework 3.5 SP1 Beta is not installed if Microsoft .NET Framework 3.5 Client Beta 1 is already installed on the computer.

    To resolve this issue:

    1. Open Add or Remove Programs.
    2. Uninstall "Microsoft .NET Framework 3.5 Client Beta 1".
    3. Uninstall "Microsoft .NET Framework 3.0 Client Beta 1".
    4. Uninstall "Microsoft .NET Framework 2.0 Client Beta ".

    2.1.8. .NET Framework Setup Failure in SP1 Beta

    In Windows XP, the .NET Framework setup program fails because failures in Internet Information Services (IIS) Setup are treated as errors instead of warnings. This issue does not occur on a computer that already has .NET Framework 3.0 installed.

    To resolve this issue:

    Reinstall the .NET Framework.

    2.1.9. .NET Framework 2.0 SP2 installation fails to upgrade .NET Framework 2.0 or 2.0 SP1

    .NET Framework 2.0 SP2 installation fails on a computer that has the .NET Framework 2.0 or 2.0 SP1 installed and that is running Windows XP, Windows Server 2003, or Windows 2000.

    The .NET Framework 2.0 SP2 setup is a major upgrade that uninstalls earlier versions of the .NET Framework 2.0 and 2.0 SP1. When Windows Installer uninstalls previous versions, it relies on using the cached installation database and all updates. If Windows Installer cannot find the install packages for the earlier installed updates during the uninstall operation in its cache, or original source location, the installation fails. If an incomplete rollback occurs, this failure to install may also cause applications that use the .NET Framework to fail.

    This problem may occur for one of the following two reasons:

    The Windows Installer cache is missing necessary files

    The Windows Installer cache is critical for repairing, for updating, and for uninstalling products. Therefore, you should not remove or modify the contents of the cache. If you change the contents of the cache, you may be prompted for a source when you try to update or to repair Windows Installer-based products.

    Sometimes a Windows Installer Patch (.msp) file that Windows Installer expects to find in the cache may not exist. The following are two common reasons why the .msp file may be missing:

    If this issue occurs, you see the following in the Windows Installer log for the failing installation:

    MSI (s) (D0:B0) [19:05:57:843]: Couldn't find local patch 'C:\WINDOWS\Installer\a4784a.msp'. Looking for it at its source. MSI (s) (D0:B0) [19:05:57:843]: Resolving Patch source.

    You can use the Microsoft .NET Framework Registration Correction Tool to resolve this issue when it occurs when you install the .NET Framework 2.0 SP2. The tool fixes this issue by deleting all hotfix or update registrations that are specific to this update so that maintenance installations do not try to load the specific .msp file.

    You can also try to fix this issue by rebuilding the installer cache. You can typically find the Knowledge Base number for the hotfix or for the update in the lines that follow "Resolving Patch source," as shown in the following example:
    MSI (s) (D0:B0) [19:05:57:859]: SOURCEMGMT: Source is invalid due to missing/inaccessible package.
    MSI (s) (D0:B0) [19:05:57:859]: Note: 1: 1706 2: -2147483647 3: NDP20-KB917283-X86.msp

    To fix the Windows Installer Cache for this example, follow these steps:
    1. Visit the following Microsoft Web site: http://support.microsoft.com/kb/917283 (http://support.microsoft.com/kb/917283) Note You can replace the Knowledge Base article number in the URL with the Knowledge Base article number of the hotfix or the update for which you want to fix the Windows Installer cache.
    2. Download the update.
    3. Extract the .msp file that is inside the hotfix or the update by using the /x command-line switch or the /extract command-line switch.
    4. Copy the extracted .msp file to the location for the missing file. In this example, the location is %windir%\Installer\a4784a.msp.

    The hotfix registration or the update registration is corrupted

    After a hotfix or an update is installed on a Windows Installer-based product, the hotfix registration or the update registration may become corrupted. This problem can occur because of third-party registry cleaner utilities that remove certain registry keys. These keys include the keys that are meant for internal use by Windows Installer. In this case, the "Resolving Patch source" message in the log reads as follows:
    MSI (s) (CC:5C) [03:02:56:181]: Couldn't find local patch ''. Looking for it at its source.
    MSI (s) (CC:5C) [03:02:56:181]: Resolving Patch source.

    Note The location of the hotfix or the update is missing in the log message because of the missing hotfix or upate registration information. In this case, a hotfix or an update is still registered to a product. However, location information for the hotfix or update is missing. Although the file may exist, Windows Installer does not know the path of the file that Windows Installer needs in order to load.
    You can use the Microsoft .NET Framework Registration Correction Tool to resolve this issue when it occurs when you install the .NET Framework 2.0 SP2. The tool fixes this issue by deleting all hotfix or update registration that is specific to this service pack so that maintenance installations do not try to load the hotfix or the update package.

    To resolve this issue:

    If you cannot successfully install the .NET Framework 2.0 SP2 and find the "Resolving Patch source" text in the installation log file as described in the “Cause” section, you can download the Microsoft .NET Framework Registration Correction Tool to resolve this issue.
    The Microsoft .NET Framework Registration Correction Tool resolves both of the issues that the "Cause" section describes.

    The following file is available for download from the Microsoft Download Center: http://www.microsoft.com/downloads/details.aspx?FamilyID=0BA6038C-061E-4B4A-9BE9-96A323701260

    The Microsoft Download Center has one version of the tool for each processor architecture that the .NET Framework 2.0 supports (x86, x64, and IA-64). Most customers run a 32-bit version of the operating system. Therefore, these customers need to download and to install the x86 version of the tool.

    Administrators may also use this utility in scripts by passing either the /q command-line switch or the /quiet command-line switch. In this way, you can run the application in silent mode without using a user interface and without using block scripts.

    The tool writes a running log under the %TEMP%\dd_clwireg.txt folder. You can view this log for more information about what the tool is doing.

    Notes

    2.2. Uninstalling

    There's no known issue.

    2.3. Product Issues

    2.3.1 General Issues

    There's no known issue.

    2.3.2 Windows Communication Foundation (WCF)

    2.3.2.1 HTTP POX is not composable with One-way

    The OneWayBindingElement class is designed to create client-side channels that expect null messages as responses; otherwise, it fails with a ProtocolException error. Standard message encoders return messages that have a non-empty message body. However, in a POX/REST scenario, you may want to process messages based solely on the contents of HTTP headers (for example, 200 for success; otherwise, failure), rather than the message body. Because message encoders do not let you return null messages based on HTTP headers in these scenarios, it is not possible to use OneWay contracts on the client side.

    To resolve this issue:

    In the channel stack configuration, add a filter channel between OneWayBindingElement and HttpTransportBindingElement that checks the HTTP response status code. If the code indicates success, it returns null; otherwise, it returns the original response message. The final configuration appears as follows, with a custom binding element that filters the responses.

    CustomBinding binding = new CustomBinding(
                  new OneWayBindingElement(),
                  new MyMessageFilterByHttpHeaders(),
                  new TextMessageEncodingBindingElement(),
                  new HttpTransportBindingElement()
    );
    binding.Elements.Find<MessageEncodingBindingElement>().MessageVersion = MessageVersion.None;

    2.3.2.2 Windows XP issue when AllowNtlm is set to false

    In WCF, if you specify the clientCredentialtype property as Windows and negotiate the client credentials, you can enable NTLM to be used as a negotiation package. The default behavior for WSHttpBinding and WS2007WttpBinding is to negotiate Windows client credentials. You can control this behavior in WCF by modifying the allowNtlm property. In the .config file, put the clientCredentials tag in an endpointBehavior tag. In the code, set a property on WindowsClientCredentials. There is a behavior change in SP1 that affects WCF running on all versions of Windows later than Windows XP. When allowNtlm is set to false, WCF in .NET Framework versions 3.0 and 3.5 would instruct spnego to use Kerberos as the negotiation package. The behavior change in SP1 excludes NTLM by passing additional information to the negotiation layer. This change enables additional sspi packages to be negotiated if they are available and supported by future versions of Windows. However, this functionality is not available in Windows XP, and users who set the AllowNtlm to false will experience problems.

    To resolve this issue:

    Set SecureConversation to false when you set AllowNtlm to false.

    2.3.3 Windows Presentation Foundation (WPF)

    2.3.3.1 Important Requirement for Windows Vista

    To run Windows Presentation Foundation (WPF) Applications with this package you will need to have installed Windows Vista SP1 or install the Microsoft Visual C++ 2005 SP1 Redistributable Package:

    2.3.4 Windows Workflow Foundation (WF)

    There's no known issue.

    3. Related Links

    3.1. Visual Studio 2008 Service Pack 1 Beta Readme:  http://go.microsoft.com/fwlink/?LinkId=110456.

    3.2. Visual Studio 2008 Express Editions Readme:http://go.microsoft.com/fwlink/?LinkID=111607.

    © 2008 Microsoft Corporation. All rights reserved. Terms of Use  | Trademarks  | Privacy Statement