Microsoft .NET Framework 3.5 Issues

2.1.1. Uninstall earlier pre-release versions of .NET Framework 3.5 prior to installing
the released version.
If you have installed earlier pre-release versions of .NET Framework 3.5, then you
must uninstall them prior to running this installation by using Add or Remove Program.
To resolve this issue:
There's no workaround available.

2.1.2. Installing .NET Framework 2.0 or .NET Framework 3.0 stand-alone ENU language
package MSU (shipped on media) but the .NET Framework 2.0 or .NET Framework 3.0
language package is already installed.

When one of the following files is being installed, a message, "the following updates
were not installed" is displayed.WCU\dotNetFramework\dotNetMSP\x64\NetFX2.0-KB936704-v6000-x64_RTM_en.msu
WCU\dotNetFramework\dotNetMSP\x64\NetFX3.0-KB936705-v6000-x64_RTM_en.msu
WCU\dotNetFramework\dotNetMSP\x86\NetFX2.0-KB936704-v6000-x86_RTM_en.msu
WCU\dotNetFramework\dotNetMSP\x86\NetFX3.0-KB936705-v6000-x86_RTM_en.msu
This happens because the corresponding .NET Framework 2.0 or .NET Framework 3.0
En-US language package is already installed.
To resolve this issue:Install .NET Framework 3.5 by using the installation instructions on
http://go.microsoft.com/fwlink/?LinkId=96339.
2.1.3. .NET Framework 3.5 does not install on Windows Server 2003 Itanium architectures.

Installing .NET Framework 3.5 on Windows Server 2003 for Itanium 64-bit processors
produces the following message: "Microsoft .NET Framework 3.5 - You must first install
Microsoft .NET Framework 2.0 SP1 before installing or repairing".
To resolve this issue:
No workaround is available. .NET Framework 3.5 is not supported on Windows 2003
for Itanium 64-bit processors.

2.1.4. .NET Framework 3.5 installation might not configure IIS correctly on Windows
XP or Windows Server 2003

Installation of .NET Framework 3.5 will not configure IIS correctly on Windows XP
or Windows Server 2003 if IIS is already installed and the IIS Admin Service is
disabled.

To resolve this issue:

Do the following things after you install .NET Framework 3.5

1. On the Start menu, click Run.

2. Type "cmd" and then press ENTER.

3. Type "sc config iisadmin start= auto" and then press ENTER.


-or-

1. On the Start menu, click Run.
2. Type "services.msc" and then press ENTER.
3. Select the IIS Admin Service from the list. If the Startup Type is Disabled,
right-click IIS Admin Service and then click Properties. Change Startup Type to
Automatic.
4. In %WINDIR%\Microsoft.NET\Framework\v3.5\, run WFServicesReg.exe /c. (On
64-bit computers, the path is %WINDIR%\Microsoft.NET\Framework64\v3.5\.)

2.1.5. .NET Framework 3.5 reinstallation displays a re-try dialog box.

When customers install .NET Framework 3.5 and then reinstall it, they may see a
re-try dialog box that prompts them to close Setup.

To resolve this issue:
Clicking the retry button is harmless. Setup will typically continue because an
instance of Setup is already running.

2.1.6. Upgrading .NET Framework 3.5 Beta 1 to the release version might fail on
Windows Vista RTM.

User installs .NET Framework 3.5 Beta 1 on Windows Vista and then upgrades to the
.NET Framework 3.5 release version. .NET Framework 2.0 and .NET Framework
3.0 files might not be correctly upgraded if Windows Vista Beta 1 updates are not
removed first.
To resolve this issue:
1। If you have already tried to install .NET Framework 3.5, uninstall it.2. Uninstall the following KBs by using Installed Updates.- KB929300
- KB930264
- KB110806
3. Install .NET Framework 3.5.2.1.7. Download of .NET Framework Setup fails.2.1.7.1. Configuration ErrorsThis error occurs when BITS interfaces are not registered or the registry settings
are corrupted.To resolve this issue:

- Upgrade to BITS 2.0 from
http://www.microsoft.com/downloads/details.aspx?FamilyId=B93356B1-BA43-480F-983D-EB19368F9047&displaylang=en

-or-

- Repair the BITS service by running the Bitsadmin tool at the command prompt, as
follows: bitsadmin /util /repairservice /force

You can download the Bitsadmin tool from:
http://www.microsoft.com/downloads/details.aspx?amp;displaylang=en&familyid=49AE8576-9BB9-4126-9761-BA8011FABF38&displaylang=en.

2.1.7.2. Network Errors

These errors may occur for the following reasons:


- Unable to reach download server.


- URL not found on the server.


- Server is overloaded.


- Bad Gateway or Proxy.


- Network is disconnected.


- Proxy does not support HTTP 1.1.


To resolve this issue:

1. Make sure that you are connected to the network. You may have to exit Setup.

2. Do one of the following things.

- Provide correct settings for the proxy server and ensure that your computer can
correctly resolve the proxy server.


-or-

- Upgrade to BITS 2.0. You can download BITS 2.0 from



http://www.microsoft.com/downloads/details.aspx?amp;displaylang=en&familyid=49AE8576-9BB9-4126-9761-BA8011FABF38&displaylang=en
.


2.1.7.3. Disk Errors

This error occurs when the BITS service failed to create a file or write to a file.
Because another program, such as chkdsk.exe, might be running, the disk might be
locked and BITS might be prevented from writing to the file.

To resolve this issue:

- Make sure that no other program
that could lock the disk is running and then try the download again.

-or-

- Restart the computer and then run Setup again. Make sure that you are connected
to the Internet.


2.1.7.4.Proxy Errors

The BITS service failed because of one of the following proxy-related errors:


- The Proxy settings are not valid.

- The proxy server requires authentication.

- The computer is not able to resolve the proxy server.

To resolve this issue:

- Provide correct credentials for
proxy server authentication and then start Setup again.

-or-

- Upgrade the proxy server to support HTTP1.1 and ensure that the proxy supports
implicit credentials (for example, NTLM). You may have to contact your network administrator.

-or-

Bypass the proxy server by changing your Internet Explorer proxy settings.

To bypass a proxy server:

1. In Internet Explorer, click Tools and then click Internet Options.

2. Click the Connections tab and then click LAN Settings.

3. Under Proxy server, clear Use a proxy server for your LAN (These settings will
not apply to dial-up or VPN connections.) and then click OK.

4. Click OK again.

If you need further assistance with your proxy server settings, contact your network
administrator.

2.1.7.5. Other Errors

The BITS Service does not run in the following scenarios:


- Safe-boot mode.


- On Windows 2000 from a remote desktop connection.


- When Setup is installed by using a "run as" command.


To resolve this issue:

No workaround is available. These scenarios are not supported.

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




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

To resolve this issue:



1. Uninstall .NET Framework 3.5.

2. Reinstall .NET Framework 3.5 from the Visual Studio 2008 DVD or from
http://www.microsoft.com.

2.1.9. .NET Framework 2.0 SP1 Setup fails on Windows 2000 SP4 and displays the error
message, "The procedure entry point HeapSetInformation could not be located in the
dynamic link library KERNEL32.dll."


.NET Framework 2.0 SP1 Setup fails on Windows 2000 SP4 and displays the error 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.10. During .NET Framework installation or uninstalling, a dialog pops up and
asks you to close setup process.

During Installation or Uninstalling of .NET Framework 3.5, .NET Framework 3.0 Service
Pack 1, and .NET Framework 2.0 Service Pack 1, a dialog pops up with the message
"The following application should be closed before continuing with setup:"

The list of applications shown contains the setup itself, and looks like the below:

Microsoft .NET Framework 3.5 Setup

setup

To resolve this issue:

Click on "Ignore" and continue with setup.


2.1.11. "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.3. Product Issues


2.3.1. General Issues


2.3.1.1. Repairing .NET Framework 3.0 SP1 by using the Support Info dialog box in
Add or Remove Programs requires the user to specify the path of the product installation
source.


Repairing .NET Framework 3.0 SP1 by using the Support Info dialog box in Add or
Remove Programs requires the user to specify the path of the product installation
source.


To resolve this issue:



Repair .NET Framework 3.0 SP1 by using the Change option in Add or Remove Programs.

2.3.1.2. Enabling ASMX tracing breaks SqlString serialization.




Enabling ASMX tracing for an ASP.NET Web service that sends or receives a SqlString
instance results in an ArgumentOutOfRangeException error at run time.

To resolve this issue:

Disable ASMX tracing for the ASP.NET Web service.


2.3.1.3. The COM registration for System.Management.Instrumentation.dll, which is
included with .NET Framework 3.5, is incorrect because it assumes that the version
is 2.0.0.0 when it is actually 3.5.0.0.




Windows Management Instrumentation (WMI) clients get a “Provider Load Failure” error
when they attempt to use functionality that is implemented in a WMI provider that
leverages the WMI Provider Extensions infrastructure. The cause is an improperly-registered
dynamic-link library (DLL). During installation of the .NET Framework 3.5, the System.Management.Instrumentation.dll
is not correctly registered to enable COM clients to use the classes that it implements.

To resolve this issue:



1. Click Start, and click All Programs.

2. Click Microsoft Visual Studio 2008 and then click Visual Studio Tools.

3. On Windows operating systems earlier than Windows Vista, click Microsoft Visual
Studio 2008 Command Prompt to open a Command Prompt window. On Windows Vista and
later operating systems, right-click Microsoft Visual Studio 2008 Command Prompt
and then click Run as Administrator to open an elevated Command Prompt window.

4. At the command prompt, type "regasm %systemdrive%\program files\reference assemblies\microsoft\framework\v3.5\system.management.instrumentation.dll"
and then press ENTER.

Note: Developers who are writing WMI providers that leverage the WMI Provider Extensions
technology (included in .NET Framework 3.5) must ensure that System.Management.Instrumentation.dll
is registered properly, and fix the registration if necessary, before they install
their providers. Incorrect registration will result in provider failure. The procedure
at http://go.microsoft.com/fwlink/?LinkID=103794
shows how to register this DLL correctly.

2.3.1.4. In ASP.NET, LinqDataSource throws System.Security.SecurityException at
run time.




As part of the .NET Framework 3.5 Setup, some permissions are added to the default
configuration files, web_mediumtrust.config and web_hightrust.config. These
updates are required so that LinqDataSource can be used in medium trust and high
trust settings.



Custom trust configuration files cannot be detected by the installer and must be
updated manually. If trust settings are not updated, the
LinqDataSource control may raise the following runtime exception: "System.Security.SecurityException:
Request for the permission of type 'System.Security.Permissions.ReflectionPermission,
mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed."
To resolve this issue:1. Open the trust configuration file that would typically be installed in the following
location: %WINDIR%\Microsoft.NET\Framework\v2.0.50727\CONFIG\.2. Make the following two changes in this file:- Under the <SecurityClasses> element, add a nested entry for a new Security
Class, as follows:<SecurityClasses>


....
<!-- this SecurityClass section is
the work around for the compilation issue -->
<SecurityClass




Name="ReflectionPermission"




Description="System.Security.Permissions.ReflectionPermission,




mscorlib,




Version=2.0.0.0, Culture=neutral,




PublicKeyToken=b77a5c561934e089"


/>

</SecurityClasses>







- In the <NamedPermissionSets> section, nested in the ASP.NET <PermissionSet>,
add a <IPermission> element for
reflection permission, as follows:




<NamedPermissionSets>




<PermissionSet


class="NamedPermissionSet"


version="1"


Name="ASP.NET">


...

<!-- this IPermission
section is the work around for the reflection issue -->

<IPermission


class="ReflectionPermission"


version="1"


Flags="RestrictedMemberAccess"

/>

</PermissionSet>

...



</NamedPermission>



3. Save the file and close it.2.3.1.5. On Windows XP, existing managed control URL actions for current user are
overwritten when user upgrades to .NET Framework 2.0, .NET Framework 3.0, or .NET
Framework 3.5.




When the runtime is upgraded from .NET Framework 2.0 or .NET Framework 3.0 to .NET
Framework 3.5, any of the existing managed code URL actions for the current user
are overwritten by the default settings. For example, URL actions that the user
set to "Disabled" could be reset to the default "Enabled".


The following two URL actions are known to be affected: “Run components not signed
with Authenticode” and “Run components signed with Authenticode”.

This behavior occurs on Windows XP, but does not occur on Windows 2003 and Windows
Vista.


This behavior also occurs when .NET Framework 1.1 is upgraded to .NET Framework
2.0.

To resolve this issue:



The user must reset URL actions manually after a .NET Framework upgrade.


2.3.1.6. Internet Explorer Setup resets the URL action "Permissions for Components
with Manifests" from "Disabled" to "High Safety" during installation.




When Internet Explorer 6 is upgraded to Internet Explorer 7, if the URL action "Permissions
for Components with Manifests" is set to "Disabled", it is changed to "High Safety"
(the default). This occurs because Internet Explorer 7 Setup does not know that
the URL action has been changed from the default; therefore, it resets it to the
default. This is noteworthy because the default Medium-High security setting may
be less restrictive than the user's previously chosen setting.

To resolve this issue:



The user must reset URL actions manually after an upgrade.

2.3.2. Windows Communication Foundation
(WCF)


2.3.2.1. wsHttpBinding that has message security sign-only contract requirements
produces non-compliant messages.


WCF emits a <sp:EncryptSignature> assertion in the service’s security policy
every time the message security is used in the wsHttpBinding binding. To make WCF
compliant with the security policy specification, it does not emit the <sp:EncryptSignature>
assertion if the entire service contract is marked as ProtectionLevel.Sign or ProtectionLevel.None
and nothing is encrypted in any contract’s operation message (for example, username
token).


To resolve this issue:



No workaround is available.

2.3.2.2. Cannot resolve relative externalMetadataLocations when HTTPS and configured
MEX endpoints are used.



When metadata publishing for a WCF service over HTTPS is configured by using ServiceMetadataBehavior
with a relative ExternalMetadataLocation, metadata requests cannot be resolved and
the following exception message is displayed if any metadata exchange (MEX) endpoints
are configured: "The URL supplied to ServiceMetadataBehavior via the ExternalMetadataLocation
property or the externalMetadataLocation attribute in the serviceMetadata section
in config was a relative URL and there is no base address with which to resolve
it."

To resolve this issue:

Remove any configured MEX endpoints from the WCF service.


2.3.2.3. Behavior change: SSL certificates validation and certificate paths.


In earlier releases, if IIS or any other Web server was configured to use HTTPS
and to exchange the whole server certificate path instead of just the server certificate,
a WCF client might not have accepted the server's certificate as valid when intermediate
CA certificate(s) did not exist in the local certificate store. In .NET Framework
version 3.5, WCF now handles the certificate paths for server certicate verification.


To resolve this issue:



No workaround is required.

2.3.4.1. Workflow Foundation rules cannot use non-public extension methods.


Non-public extension methods that are defined in a workflow project cannot be used
as part of Workflow Foundation rules.


To resolve this issue:

Make the extension methods public.