Microsoft .NET Framework 3.5 أخيرا الإصدار النهائى من ميكروسوفت كامل برابط واحد مباشر

35 , framework , microsoft , net , كامل , واحد , ميكروسوفت , من , مباشر , أخيرا , النهائى , الإصدار , برابط

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 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

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

The .NET framework 2.0 SP2 Setup uninstalls earlier versions of the .NET framework 2.0 and 2.0 SP1. When Windows Installer uninstalls previous versions, it uses the cached installation database. During the uninstall operation, if Windows Installer cannot find the installation packages for the earlier updates in its cache, or the 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 either of these reasons:

The Windows Installer cache is missing required files.

The Windows Installer cache has been changed. The cache is critical for repairing, for updating, and for uninstalling products. Therefore, do 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:
- A tool that finds and deletes large files or rarely used files on the hard disk has been run.
- The owner of the %windir%\Installer directory is changed from SYSTEM or from Administrators.

If this issue occurs, the Windows Installer log for the failing installation will show something that resembles the following:
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. 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 in the hotfix or the update by using the /x command-line switch or the /extract command-line switch.
4. opy 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 may be 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 requires to load.

You can use the microsoft .NET framework Registration Correction Tool to resolve this issue when it occurs. 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.

If you cannot successfully install .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.

microsoft .NET framework 2.0 Registration Correction Tool
The microsoft .NET framework Registration Correction Tool resolves both of the issues that the "Cause" section describes.
The following file is available for download on the microsoft Download Center:

Download the microsoft .NET framework 2.0 Registration Correction Tool package now. http://www.microsoft.com/downloads/d...9-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 should download and 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
- The microsoft .NET framework Registration Correction Tool is designed to be used with any current version of the .NET Framework.
- You must be an administrator to run this utility.

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

1. Open Control Panel and go to Programs and Features.

2. Uninstall .NET framework 3.5.

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

The .NET framework 3.5 SP1 Setup fails on Windows Vista and Windows 2008 Server, with the 1058 error code.

Before you install .NET framework 3.5 SP1 on Windows Vista or Windows 2008 Server, make sure that Windows Update service is turned on.

.NET framework 3.5 SP1 language pack fails to install on Windows 2008 Server if the matching operating system language pack is not installed.

Install the matching operating system language pack before you install the .NET framework 3.5 SP1. You can obtain the operating system language pack from http://www.microsoft.com/Downloads/details.aspx?FamilyID=e9f6f200-cfaf-4516-8e96-e4d4750397ff&displaylang=en.

There are no known issues.

When the following conditions are true...
- A WCF client or service is configured with a binding that has security mode = TransportWithMessageCredentials and a symmetric key-based endorsing supporting token (such as a symmetric key-issued token).
- The service or client receives a message that has the To header signed and referenced after the TimeStamp element in the Signature element, as in the following example:

&ltds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="Signature-9199266">
&ltds:SignedInfo>
&ltds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></ds:CanonicalizationMethod>
&ltds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"></ds:SignatureMethod>
&ltds:Reference URI="#Timestamp">
&ltds:Transforms>
&ltds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></ds:Transform>
</ds:Transforms>
&ltdsigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></dsigestMethod>
&ltdsigestValue&gt...</dsigestValue>
</ds:Reference>
&ltds:Reference URI="#To">
&ltds:Transforms>
&ltds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></ds:Transform>
</ds:Transforms>
&ltdsigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></dsigestMethod>
&ltdsigestValue&gt...</dsigestValue>
</ds:Reference>
</ds:SignedInfo>
&ltds:SignatureValue&gt...</ds:SignatureValue>
&ltds:KeyInfo&gt...</ds:KeyInfo>
</ds:Signature>
...the following exception is thrown:

"System.Security.Cryptography.CryptographicExcepti on, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089

Unable to resolve the '#To' URI in the signature to compute the digest.

at System.IdentityModel.StandardSignedInfo.EnsureAllR eferencesVerified()
at System.IdentityModel.SignedXml.CompleteSignatureVe rification()
at System.ServiceModel.Security.WSSecurityOneDotZeroR eceiveSecurityHeader.VerifySignature(SignedXml signedXml, Boolean isPrimarySignature, SecurityHeaderTokenResolver resolver, Object signatureTarget, String id)
at System.ServiceModel.Security.ReceiveSecurityHeader .ProcessSupportingSignature(SignedXml signedXml, Boolean isFromDecryptedSource)
at System.ServiceModel.Security.ReceiveSecurityHeader .ExecuteFullPass(XmlDictionaryReader reader)
at System.ServiceModel.Security.StrictModeSecurityHea derElementInferenceEngine.ExecuteProcessingPasses( ReceiveSecurityHeader securityHeader, XmlDictionaryReader reader)
at System.ServiceModel.Security.ReceiveSecurityHeader .Process(TimeSpan timeout)
at System.ServiceModel.Security.AcceptorSessionSymmet ricTransportSecurityProtocol.VerifyIncomingMessage Core(Message&amp; message, TimeSpan timeout)
at System.ServiceModel.Security.TransportSecurityProt ocol.VerifyIncomingMessage(Message&amp; message, TimeSpan timeout)"

To resolve this issue:
Do not sign the To header.

The Assembly Cache Viewer (Shfusion.dll) is a Windows shell extension that lets you view and manipulate the contents of the global assembly cache by using Windows Explorer. Shfusion.dll is located in the %windir%\Microsoft.NET\Framework\v2.0.50727 directory.

In Windows Vista, the Assembly Cache Viewer does not run with elevated permissions even if you run it from a Command Prompt window that has elevated permissions (for example, by using the START command with the path of the global assembly cache). This is because the Assembly Cache Viewer is a shell extension for Windows Explorer, which does not run with elevated permissions.

Use Shfusion.dll only for viewing.

For updates, open a Command Prompt window that has administrative privileges and use the Gacutil.exe command-line tool from the .NET framework SDK.

Known Issues in ASMX Web Services:

To resolve this issue:

---

---

---

Workaround options:

Commands executed within the context of an OracleTransaction will not be rolled back when the transaction is rolled back or aborted. This can occur in applications using the managed Oracle provider System.Data.OracleClient.

To resolve this issue:
Disable connection pooling and create a new OracleConnection object for every OracleTransaction.

WCF now specifies a default domain target name in Windows authentication scenarios. When upgrading, the client may see an authentication failure when the following conditions exist:

An example of the authentication failure is "System.ComponentModel.Win32Exception The target principal name is incorrect"
To resolve this issue:
The client must override the default domain target name by specifying the Service Principal Name of the server in the SpnEndpointIdentity class, or User Principal Name in the UpnEndpointIdentity class, and then passing the identity to the EndpointAddress. If the client uses Https and requires X509CertificateEndpointIdentity, the client must still specify the SpnEndpointIdentity or UpnEndpointIdentity. The X509CertificateEndpointIdentity enables validation of thumbprints. The client can work around the loss of validation by registering for the System.Net.ServicePointManager.ServerCertificateVa lidationCallback and performing thumbprint validation manually.

When WSHttpBinding, WS2007HttpBinding, or NetTcpBinding is used with SecurityMode = TransportWithMessageCredential and a client credential type of Windows, clients that previously authenticated to a service by using NTLM will now fail to authenticate, with the following error:

"System.ComponentModel.Win32Exception: Security Support Provider Interface (SSPI) authentication failed. The server may not be running in an account with identity 'host/<hostname>'. If the server is running in a service account (Network Service for example), specify the account's ServicePrincipalName as the identity in the EndpointAddress for the server. If the server is running in a user account, specify the account's UserPrincipalName as the identity in the EndpointAddress for the server."

The error appears when the service is running on an account that has an identity other than 'host/<hostname>'. This issue also applies to CustomBindings, which specify the SspiNegotiatedOverTransport authentication mode.

To resolve this issue:
If possible, clients should be updated by using a UPN or SPN endpoint identity that specifies the identity of the service so that Kerberos authentication occurs. The following configuration snippet shows how to do this in the UPN case; the SPN case is similar, but the <servicePrincipalName> element is used instead.
<system.serviceModel>
<client>
<endpoint>
<identity>
<userPrincipalName value="user@domain" />
</identity>
</endpoint>
</client>
</system.serviceModel>

Additionally, clients that use NetTcpBinding or CustomBindings, with SspiNegotiatedOverTransport specified in the stack over SslStreamSecurityBindingElement, must specify a custom IdentityVerifier in the code to perform the CN check of the service's certificate. The following code snippet shows how to do this and provides a starting point for IdentityVerifier implementations.

NetTcpBinding tcpBinding = new NetTcpBinding(SecurityMode.TransportWithMessageCre dential);
CustomBinding customBinding = new CustomBinding(tcpBinding.CreateBindingElements());
SslStreamSecurityBindingElement ssl = customBinding.Elements.Find<SslStreamSecurityBindi ngElement>();
ssl.IdentityVerifier = new DnsIdentityVerifier(new DnsEndpointIdentity("DNS.name.of.service.certifica te"));

public class DnsIdentityVerifier : IdentityVerifier
{
DnsEndpointIdentity _expectedIdentity;

public DnsIdentityVerifier(DnsEndpointIdentity expectedIdentity)
{
_expectedIdentity = expectedIdentity;
}

public override bool CheckAccess(EndpointIdentity identity, AuthorizationContext authContext)
{
List<Claim> dnsClaims = new List<Claim>();

foreach (ClaimSet claimSet in authContext.ClaimSets)
{
foreach (Claim claim in claimSet)
{
if (ClaimTypes.Dns == claim.ClaimType)
{
dnsClaims.Add(claim);
}
}
}

if (1 != dnsClaims.Count)
{
throw new InvalidOperationException(String.Format("Found {0} DNS claims in authorization context.", dnsClaims.Count));
}
return String.Equals((string)_expectedIdentity.IdentityCl aim.Resource, (string)dnsClaims[0].Resource, StringComparison.OrdinalIgnoreCase);
}

public override bool TryGetIdentity(EndpointAddress reference, out EndpointIdentity identity)
{
identity = _expectedIdentity;
return true;
}
}

Using path combine operations (Unite, Divide, Intersect, Subtract, and Exclude Overlap) in Expression Blend can create more path points than are required to represent the combine result.

For more information about this issue, visit here.

There are no known issues.

المصدر: منتديات لحظات لايف -||- من قسم: نظم التشغيل و ملحقات وصيانة الحاسب