1.1. Unterstützte Architekturen
.Die Installation von NET Framework 2.0 SP2 schlägt möglicherweise auf einem Computer fehl, auf dem .NET Framework 2.0 oder 2.0 SP1 installiert ist und Windows XP, Windows Server 2003 oder Windows 2000 ausgeführt wird.
Das .NET Framework 2.0 SP2-Setup deinstalliert frühere Versionen von .NET Framework 2.0 und 2.0 SP1. Windows Installer verwendet zur Deinstallation früherer Versionen die zwischengespeicherte Installationsdatenbank. Wenn Windows Installer bei der Deinstallation die Installationspakete für die früheren Updates im Cache oder dem Speicherort der ursprünglichen Quelle nicht finden kann, schlägt die Installation fehl. Bei einem unvollständigen Rollback werden durch diesen Fehler möglicherweise auch bei auf .NET Framework angewiesenen Anwendungen Fehler verursacht.
Dieses Problem kann aus einem der folgenden Gründe auftreten:
Im Cache von Windows Installer sind erforderliche Dateien nicht vorhanden.
Der Cache von Windows Installer wurde geändert. Der Cache ist zur Reparatur, Aktualisierung und Deinstallation von Produkten erforderlich. Der Cacheinhalt sollte daher nie entfernt oder geändert werden. Wenn Sie die Cacheinhalte ändern, werden Sie möglicherweise beim Versuch, ein auf Windows Installer basierendes Produkt zu aktualisieren oder zu reparieren, zur Angabe einer Quelle aufgefordert.So beheben Sie dieses Problem
Wenn Sie .NET Framework 2.0 SP2 nicht erfolgreich installieren können und den im Abschnitt "Ursache" beschriebenen "Resolving Patch source"-Text in der Protokolldatei der Installation nicht finden können, können Sie zur Lösung dieses Problems das Microsoft .NET Framework-Registrierungskorrekturtool herunterladen.
Einige Komponenten von .NET Framework 3.5 sind nach einer Aktualisierung von Windows XP oder Windows Server 2003 auf Windows Vista (RTM) auf dem Computer nicht vorhanden.
So beheben Sie dieses Problem
1. Öffnen Sie den Systemsteuerungseintrag Programme und Funktionen.
2. Deinstallieren Sie .NET Framework 3.5.
3. Installieren Sie .NET Framework 3.5 von der Visual Studio 2008-DVD oder von http://www.microsoft.com erneut.
Das Setup für .NET Framework 3.5 SP1 schlägt unter Windows Vista und Windows 2008 Server mit dem Fehlercode 1058 fehl.
So beheben Sie dieses Problem
Stellen Sie vor der Installation von .NET Framework 3.5 SP1 unter Windows Vista oder Windows 2008 Server sicher, dass der Windows Update-Dienst aktiviert ist.
Die Installation des Language Pack für .NET Framework 3.5 SP1 unter Windows 2008 Server schlägt fehl, wenn nicht das entsprechende Language Pack für das Betriebssystem installiert ist.
So beheben Sie dieses Problem
Installieren Sie das entsprechende Language Pack für das Betriebssystem, bevor Sie .NET Framework 3.5 SP1 installieren. Sie können das Language Pack für das Betriebssystem unter http://www.microsoft.com/Downloads/details.aspx?FamilyID=e9f6f200-cfaf-4516-8e96-e4d4750397ff&displaylang=de beziehen.
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"></ds:SignatureMethod>
<ds:Reference URI="#Timestamp">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></ds:DigestMethod>
<ds:DigestValue>...</ds:DigestValue>
</ds:Reference>
<ds:Reference URI="#To">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></ds:DigestMethod>
<ds:DigestValue>...</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>...</ds:SignatureValue>
<ds:KeyInfo>...</ds:KeyInfo>
</ds:Signature>
...Die folgende Ausnahme wird ausgelöst:
"System.Security.Cryptography.CryptographicException, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
at System.IdentityModel.StandardSignedInfo.EnsureAllReferencesVerified()
at System.IdentityModel.SignedXml.CompleteSignatureVerification()
at System.ServiceModel.Security.WSSecurityOneDotZeroReceiveSecurityHeader.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.StrictModeSecurityHeaderElementInferenceEngine.ExecuteProcessingPasses(ReceiveSecurityHeader securityHeader, XmlDictionaryReader reader)
at System.ServiceModel.Security.ReceiveSecurityHeader.Process(TimeSpan timeout)
at System.ServiceModel.Security.AcceptorSessionSymmetricTransportSecurityProtocol.VerifyIncomingMessageCore(Message& message, TimeSpan timeout)
at System.ServiceModel.Security.TransportSecurityProtocol.VerifyIncomingMessage(Message& message, TimeSpan timeout)"
Beim Assembly Cache Viewer-Tool (Shfusion.dll, Assemblycacheanzeige) handelt es sich um eine Erweiterung der Windows-Shell, mit der der Inhalt des globalen Assemblycaches in Windows Explorer angezeigt und verändert werden kann. Shfusion.dll befindet sich im Verzeichnis %windir%\Microsoft.NET\Framework\v2.0.50727.
Unter Windows Vista wird das Assembly Cache Viewer-Tool nicht mit erweiterten Berechtigungen ausgeführt, selbst wenn Sie es von einem Eingabeaufforderungsfenster mit erweiterten Berechtigungen aus starten (beispielsweise, indem Sie den Befehl START mit dem Pfad des globalen Assemblycaches verwenden). Dies ist darauf zurückzuführen, dass das Assembly Cache Viewer-Tool eine Shell-Erweiterung ist, die nicht mit erweiterten Berechtigungen ausgeführt werden kann.
So beheben Sie dieses Problem
Verwenden Sie Shfusion.dll ausschließlich zum Anzeigen.
Öffnen Sie für Aktualisierungen ein Eingabeaufforderungsfenster mit Administratorberechtigungen, und verwenden Sie das Befehlszeilentool Gacutil.exe aus dem .NET Framework SDK.
<system.serviceModel>
<client>
<endpoint>
<identity>
<userPrincipalName value="user@domain" />
</identity>
</endpoint>
</client>
</system.serviceModel>
Weiterhin muss auf Clients, die NetTcpBinding oder CustomBindings mit im Stapel über SslStreamSecurityBindingElement festgelegter Einstellung SspiNegotiatedOverTransport verwenden, ein benutzerdefinierter Wert für IdentityVerifier im Code angegeben sein, damit die CN-Überprüfung des Dienstzertifikats ausgeführt werden kann. Dies ist im folgenden Codeausschnitt dargestellt, der außerdem als Ausgangspunkt für IdentityVerifier-Implementierungen dient.
NetTcpBinding tcpBinding = new NetTcpBinding(SecurityMode.TransportWithMessageCredential);
CustomBinding customBinding = new CustomBinding(tcpBinding.CreateBindingElements());
SslStreamSecurityBindingElement ssl = customBinding.Elements.Find<SslStreamSecurityBindingElement>();
ssl.IdentityVerifier = new DnsIdentityVerifier(new DnsEndpointIdentity("DNS.name.of.service.certificate"));
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.IdentityClaim.Resource, (string)dnsClaims[0].Resource, StringComparison.OrdinalIgnoreCase);
}
public override bool TryGetIdentity(EndpointAddress reference, out EndpointIdentity identity)
{
identity = _expectedIdentity;
return true;
}
}
So beheben Sie dieses Problem
Weitere Informationen zu diesem Problem finden Sie hier.