Infodatei zu Microsoft .NET Framework 3.5 Service Pack 1 (SP1)

Inhaltsverzeichnis

1. Systemanforderungen

1.1. Unterstützte Architekturen

  • x86
  • x64
  • ia64 (Windows Server 2008)

    1.2. Unterstützte Betriebssysteme

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

    1.3. Hardwareanforderungen

  • 620 MB Speicherplatz auf dem Systemlaufwerk
        Hinweis: Sie können das Dienstprogramm zur Datenträgerbereinigung zum Entfernen temporärer Dateien verwenden.  
  • Mindestens: CPU mit 400 MHz, Bildschirm mit einer Auflösung von 800 x 600 und 256 Farben
  • Empfohlen: CPU mit 1,0 GHz oder schneller, Bildschirm mit 1024x768 High Color, 32 Bit
  • 2. Bekannte Probleme

    2.1 Installieren

    2.1.1 Möglicher Fehler beim Aktualisieren der .NET Framework 2.0- oder 2.0 SP1-Installation auf .NET Framework 2.0 SP2

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

    Dies kann beispielsweise an einer fehlenden MSP (Windows Installer Patch)-Datei liegen, die von Windows Installer im Cache erwartet wird und nicht vorhanden ist. Im Folgenden sind zwei häufige Ursachen für fehlende MSP-Dateien aufgeführt:
    - Es wurde ein Tool ausgeführt, das nach großen oder selten verwendeten Dateien auf der Festplatte sucht und diese löscht.
    - Der Besitzer des Verzeichnisses %windir%\Installer wurde von SYSTEM oder von Administratoren geändert.

    Wenn dieses Problem auftritt, sollten Sie im Windows Installer-Protokoll für fehlgeschlagene Installationen nach einem Eintrag suchen, der dem folgenden Text ähnelt:
    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.
    Zur Lösung dieses Problems kann das Registrierungskorrekturtool für Microsoft .NET Framework verwendet werden. Dieses Tool behebt das Problem, indem es alle zu diesem Update gehörenden Hotfix- oder Updateregistrierungen löscht, sodass von Wartungsinstallationen nicht versucht wird, die spezifische MSP-Datei zu laden.

    Sie können auch versuchen, dieses Problem zu beheben, indem Sie den Cache des Installers neu erstellen. Sie können die Knowledge Base-Nummer für das Hotfix oder Update normalerweise in den auf "Resolving Patch source" folgenden Zeilen finden. Dies ist im folgenden Beispiel dargestellt:
    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

    Führen Sie folgende Schritte aus, um das Problem mit dem Windows Installer-Cache in diesem Beispiel zu beheben:
    1. Besuchen Sie die folgende Microsoft-Website: http://support.microsoft.com/kb/917283 (http://support.microsoft.com/kb/917283). Hinweis: Sie können die Knowledge Base-Artikelnummer in der URL durch die Knowledge Base-Artikelnummer des Hotfixes oder Updates ersetzen, für das Sie den Windows Installer-Cache beheben möchten.
    2. Laden Sie das Update herunter.
    3. Extrahieren Sie die MSP-Datei im Hotfix oder Update, indem Sie den Befehlszeilenschalter /x oder /extract verwenden.
    4. Kopieren Sie die extrahierte MSP-Datei an den Speicherort der fehlenden Datei. In diesem Beispiel lautet der Speicherort %windir%\Installer\a4784a.msp.

    Die Registrierung des Hotfixes oder des Updates kann beschädigt sein.

    Nachdem ein Hotfix oder Update auf einem auf Windows Installer basierenden Produkt installiert wurde, kann die Registrierung des Hotfixes oder Updates beschädigt sein. Dieses Problem kann aufgrund von Drittanbieterprogrammen zur Bereinigung der Registrierung auftreten, die bestimmte Registrierungsschlüssel entfernen. Zu diesen Schlüsseln gehören die Schlüssel, die für die interne Verwendung durch Windows Installer vorgesehen sind. In diesem Fall lautet die "Resolving Patch source"-Meldung im Protokoll wie folgt:
    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.
    Hinweis: Der Speicherort des Hotfixes oder Updates fehlt in der Protokollmeldung aufgrund der fehlenden Registrierungsinformationen für das Hotfix oder Update. In diesem Fall ist noch ein Hotfix oder Update für ein Produkt registriert. Die Speicherortinformationen für das Hotfix oder Update fehlen jedoch. Obwohl die Datei möglicherweise vorhanden ist, verfügt Windows Installer nicht über den Pfad der Datei, die von Windows Installer geladen werden muss.

    Zur Lösung dieses Problems kann das Registrierungskorrekturtool für Microsoft .NET Framework verwendet werden. Dieses Tool behebt das Problem, indem es alle zu diesem Service Pack gehörenden Hotfix- oder Updateregistrierungen löscht, sodass von Wartungsinstallationen nicht versucht wird, das Hotfix- oder Updatepaket zu laden.

    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.

    Microsoft .NET Framework 2.0-Registrierungskorrekturtool
    Das Microsoft .NET Framework-Registrierungskorrekturtool behebt beide im Abschnitt "Ursache" beschriebenen Probleme.
    Die folgende Datei steht im Microsoft Download Center zum Download bereit:

    Paket für das Microsoft .NET Framework 2.0-Registrierungskorrekturtool jetzt herunterladen. http://www.microsoft.com/downloads/details.aspx?FamilyID=0BA6038C-061E-4B4A-9BE9-96A323701260

    Im Microsoft Download Center steht für jede von .NET Framework 2.0 unterstützte Prozessorarchitektur (x86, x64 und IA-64) eine Version des Tools bereit. Die meisten Kunden führen eine 32-Bit-Version des Betriebssystems aus. Diese Kunden sollten daher die x86-Version des Tools herunterladen und installieren.
    Administratoren können dieses Dienstprogramm auch in Skripts verwenden, indem sie den Befehlszeilenschalter /q oder /quiet übergeben. Auf diese Weise kann die Anwendung im stillen Modus ohne die Verwendung einer Benutzeroberfläche oder eines Blockskripts ausgeführt werden.
    Das Tool schreibt ein Ausführungsprotokoll in die Datei %TEMP%\dd_clwireg.txt. In diesem Protokoll sind ausführlichere Informationen über die Aktionen des Tools enthalten.

    Hinweise
    - Das Microsoft .NET Framework-Registrierungskorrekturtool ist zur Verwendung mit allen aktuellen Versionen von .NET Framework vorgesehen.
    - Zur Ausführung dieses Dienstprogramms sind Administratorrechte erforderlich.

    2.1.2 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

    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.

    2.1.3 Aktivieren Sie den Windows Update-Dienst vor dem Installieren von .NET Framework 3.5 SP1.

    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.

    2.1.4 Die Installation des Language Pack für .NET Framework 3.5 SP1 unter Windows 2008 Server schlägt fehl.

    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.

    2.2 Deinstallieren

    Es sind keine Probleme bekannt.

    2.3 Probleme mit dem Produkt

    2.3.1Allgemeine Probleme

    2.3.1.1 Eine irreführende kryptografische Ausnahme kann ausgelöst werden, wenn ein Windows Communication Foundation (WCF)-Client oder -Dienst nicht erwartet, dass der To-Header einer eingehenden Nachricht signiert ist.

    Wenn die folgenden Bedingungen zutreffen…
    - Ein WCF-Client oder -Dienst wurde mit einer Bindung konfiguriert, die über den Sicherheitsmodus = TransportWithMessageCredentials und ein symmetrisches, schlüsselbasiertes unterzeichnendes Token (wie ein symmetrisches durch einen Schlüssel ausgegebenes Token) verfügt.
    - Der Dienst oder Client empfängt eine Nachricht, die über einen signierten To-Header sowie einen Verweis im Signaturelement nach dem TimeStamp-Element verfügt, wie im folgenden Beispiel dargestellt:

    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="Signature">

       <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


    Der "#To"-URI in der Signatur zum Berechnen des Digests konnte nicht aufgelöst werden.

    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&amp; message, TimeSpan timeout)
    at System.ServiceModel.Security.TransportSecurityProtocol.VerifyIncomingMessage(Message&amp; message, TimeSpan timeout)"


    So beheben Sie dieses Problem
    Signieren Sie den To-Header nicht.

    2.3.1.2 Ausführen von Assembly Cache Viewer unter Windows Vista

    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.

    2.3.1.3 In einem Rückgabewert (Out-Wert) eines ASMX-Dienstes hat eine Eigenschaft mit einem internen Setter den Wert NULL.

    Bekannte Probleme bei ASMX-Webdiensten: So beheben Sie dieses Problem
    Problemumgehungsoptionen:

    2.3.2 Windows Communication Foundation (WCF)

    2.3.2.1 Authentifizierungsfehler bei der Verwendung von Windows-Authentifizierung für bestimmte Transporte

    WCF gibt jetzt einen Namen für das Standarddomänenziel in Windows-Authentifizierungsszenarien an. Der Client erhält bei der Aktualisierung möglicherweise einen Authentifizierungsfehler, wenn die folgenden Bedingungen vorliegen: Ein Beispiel für einen solchen Authentifizierungsfehler könnte folgendermaßen lauten: "System.ComponentModel.Win32Exception Der Zielprinzipalname ist falsch."
    So beheben Sie dieses Problem
    Der Client muss den Namen des Standarddomänenziels außer Kraft setzen, indem der Dienstprinzipalname des Servers in der SpnEndpointIdentity-Klasse oder der Benutzerprinzipalname in der UpnEndpointIdentity-Klasse festgelegt und die Identität anschließend an die EndpointAddress übergeben wird. Wenn der Client Https verwendet und die X509CertificateEndpointIdentity erfordert, muss die SpnEndpointIdentity oder UpnEndpointIdentity trotzdem vom Client angegeben werden. Die X509CertificateEndpointIdentity ermöglicht eine Überprüfung von Fingerabdrücken. Der Verlust der Überprüfung kann auf dem Client umgangen werden, indem eine Registrierung für System.Net.ServicePointManager.ServerCertificateValidationCallback durchgeführt wird und die Überprüfung der Fingerabdrücke anschließend manuell erfolgt.

    2.3.2.2 Fehlerverursachende Änderungen im SspiNegotiatedOverTransport-Authentifizierungsmodus

    Bei der Verwendung von WSHttpBinding, WS2007HttpBinding oder NetTcpBinding mit SecurityMode = TransportWithMessageCredential und Windows-Anmeldeinformationen als Clientanmeldungstyp können Clients, die bisher für einen Dienst mit NTLM authentifiziert wurden, nicht mehr authentifiziert werden. Dabei tritt folgender Fehler auf:

    "System.ComponentModel.Win32Exception: Fehler bei der SSPI-Authentifizierung (Security Support Provider Interface). Der Server darf nicht mit einem Konto mit der Identität "Host/<Hostname>" ausgeführt werden. Wenn der Server mit einem Dienstkonto ausgeführt wird (z. B. "Netzwerkdienst"), geben Sie den Konto-SPN (ServicePrincipalName) als Identität in der EndpointAddress für den Server an. Wenn der Server mit einem Benutzerkonto ausgeführt wird, geben Sie den Konto-UPN (UserPrincipalName) als Identität in der EndpointAddress für den Server an."

    Dieser Fehler tritt auf, wenn der Dienst unter einem Konto ausgeführt wird, das über eine andere Identität als "Host/<Hostname>" verfügt. Dieses Problem besteht auch für CustomBindings, die den SspiNegotiatedOverTransport-Authentifizierungsmodus festlegen.

    So beheben Sie dieses Problem
    Clients sollten nach Möglichkeit mit einer UPN- oder SPN-Endpunktidentität aktualisiert werden, die die Identität des Diensts festlegt, damit die Kerberos-Authentifizierung stattfindet. Im folgenden Konfigurationsausschnitt ist dies für UPN dargestellt. Für SPN ist dieser Vorgang ähnlich, abgesehen davon, dass das <servicePrincipalName>-Element verwendet wird.

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

    }

    }

    2.3.3 Windows Presentation Foundation (WPF)

    2.3.3.1 Pfadkombinierungsvorgang generiert nicht notwendige Punkte in Expression Blend

    Bei der Verwendung von Pfadkombinierungsvorgängen (Unite, Divide, Intersect, Subtract und Exclude Overlap) in Expression Blend werden möglicherweise mehr Pfadpunkte erstellt als für die Darstellung des Kombinationsergebnisses erforderlich.

    So beheben Sie dieses Problem

    Weitere Informationen zu diesem Problem finden Sie hier.

    2.3.4 Windows Workflow Foundation (WF)

    Es sind keine Probleme bekannt.

    3. Weitere Links

    Infodatei zu Visual Studio
    Infodatei zu Visual Studio Express Edition


    © 2008 Microsoft Corporation. Alle Rechte vorbehalten. Nutzungsbedingungen | Marken | Datenschutzbestimmungen