Microsoft .NET Framework 3.5 Service Pack 1 (SP1) リリース ノート

目次

1. システム要件

1.1. サポートされているアーキテクチャ

  • x86
  • x64
  • ia64 (Windows Server 2008)

    1.2. サポートされているオペレーティング システム

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

    1.3. ハードウェア要件

  • システム ドライブに 620 MB の空き容量
        メモ : ディスク クリーンアップ ユーティリティを使用して一時ファイルを削除できます。  
  • 最小 : 400 MHz の CPU、解像度 800 x 600 で 256 色のディスプレイ
  • 推奨 :  1.0 GHz 以上の CPU、解像度 1,024 x 768 で High Color (32 ビット) のディスプレイ
  • 2. 既知の問題

    2.1. インストール

    2.1.1 .NET Framework 2.0 SP2 のインストール時に .NET Framework 2.0 または 2.0 SP1 のアップグレードに失敗する場合がある
             (※ .NET Framework 3.5 SP1 は .NET Framework 2.0 SP2 を内部的にインストールします)

    Windows XP、Windows Server 2003、または Windows 2000 が実行されているコンピュータで、.NET Framework 2.0 または 2.0 SP1 がインストールされている場合、.NET Framework 2.0 SP2 のインストールが失敗することがあります。

    .NET Framework 2.0 SP2 セットアップにより、もしくは .NET Framework 3.5 SP1 セットアップによって呼び出された .NET Framework 2.0 SP2 セットアップにより、.NET Framework 2.0 および .NET Framework 2.0 SP1 の以前のバージョンがアンインストールされます。  Windows インストーラによって以前のバージョンがアンインストールされる場合は、キャッシュされたインストール データベースが使用されます。Windows インストーラによるアンインストール操作中に、以前にインストールされた更新プログラムのインストール パッケージがキャッシュまたは元のソースの場所に見つからなかった場合、インストールが失敗します。不完全なロールバックが発生した場合、このインストールの失敗の影響により、.NET Framework を使用するアプリケーションが失敗する可能性もあります。

    この問題は、次のいずれかの理由で発生する可能性があります。

    Windows インストーラ キャッシュで必要なファイルが見つかりません。

    Windows インストーラ キャッシュが変更されています。キャッシュは、製品の修復、更新、およびアンインストールに不可欠です。したがって、キャッシュの内容を削除または変更しないでください。キャッシュの内容を変更すると、Windows インストーラ ベース製品を更新または修復しようとしたときにソースを要求される場合があります。

    Windows インストーラがキャッシュを探しても、Windows インストーラ更新プログラム (.msp) ファイルが見つからない場合があります。.msp ファイルが失われる一般的な理由として次の 2 つが挙げられます。
    ハード ディスクにある大きなファイルまたはあまり使用されないファイルを見つけて削除するツールを実行した。
    %windir%\Installer ディレクトリの所有者が SYSTEM または Administrators から変更された。

    この問題が発生した場合は、失敗したインストールの Windows インストーラ ログに次のようなメッセージが見つかります。
    MSI (s) (D0:B0) [19:05:57:843]: ローカルの修正プログラム 'C:\WINDOWS\Installer\a4784a.msp' が見つかりませんでした。ソースの場所で探しています。
    MSI (s) (D0:B0) [19:05:57:843]: 修正プログラムのソースを解決しています。
    この問題が発生した場合は、Microsoft .NET Framework Registration Correction Tool を使用して問題を解決できます。このツールでは、更新に固有のすべての修正プログラムまたは更新プログラムの登録を削除することにより、メンテナンス インストールで固有の .msp ファイル読み込みが試行されないようにして、問題を解決します。

    また、インストーラ キャッシュを再ビルドすることで問題を解決することもできます。次の例に示すように、修正プログラムまたは更新プログラムのサポート技術情報の番号は、通常、"修正プログラムのソースを解決しています。" に続く行で見つけることができます。
    MSI (s) (D0:B0) [19:05:57:859]: SOURCEMGMT: パッケージが見つからないか、またはアクセスできないため、ソースは無効です。
    MSI (s) (D0:B0) [19:05:57:859]: メモ : 1: 1706 2: -2147483647 3: NDP20-KB917283-X86.msp

    この例で Windows インストーラ キャッシュを修正するには、次の手順を実行します。
    1. 次の Microsoft Web サイトにアクセスします (http://support.microsoft.com/kb/917283)。メモ : この URL に含まれるサポート技術情報の記事番号は、Windows インストーラ キャッシュを修正する対象となる修正プログラムまたは更新プログラムのサポート技術情報の記事番号で置き換えることができます。
    2. 更新プログラムをダウンロードします。
    3. /x コマンド ライン スイッチまたは /extract コマンド ライン スイッチを使用して、修正プログラムまたは更新プログラムに含まれる .msp ファイルを展開します。
    4. 展開した .msp ファイルを失われたファイルの場所にコピーします。この例では、%windir%\Installer\a4784a.msp です。

    修正プログラム登録または更新プログラム登録が壊れている可能性があります。

    修正プログラムまたは更新プログラムが Windows インストーラ ベース製品にインストールされた後で、修正プログラム登録または更新プログラム登録が壊れる場合があります。サードパーティのレジストリ クリーナーにより特定のレジストリが削除された場合に、この問題が発生することがあります。これらのキーには、Windows インストーラが内部で使用するためのキーが含まれます。この場合は、次のような "修正プログラムのソースの解決" メッセージがログに表示されます。
    MSI (s) (CC:5C) [03:02:56:181]: ローカルの修正プログラム '' が見つかりませんでした。ソースの場所で探しています。
    MSI (s) (CC:5C) [03:02:56:181]: 修正プログラムのソースを解決しています。
    メモ : 修正プログラムまたは更新プログラムの登録情報が失われているために、ログ メッセージに修復プログラムまたは更新プログラムの場所が示されません。この場合、修正プログラムまたは更新プログラムは製品に登録されているにもかかわらず、修正プログラムまたは更新プログラムの場所情報がありません。ファイルが存在する可能性はありますが、Windows インストーラは読み込みに必要なファイルのパスを認識できません。

    この問題が発生した場合は、Microsoft .NET Framework Registration Correction Tool を使用して問題を解決できます。このツールでは、この Service Pack に固有のすべての修正プログラムまたは更新の登録を削除することにより、メンテナンス インストールで修正プログラムまたは更新プログラムのパッケージの読み込みが試行されないようにして、問題を解決します。

    この問題を解決するには

    .NET Framework 2.0 SP2 のインストールが失敗し、"原因" セクションに記述されているように "修正プログラムのソースを解決しています。" というメッセージがインストール ログ ファイルに表示された場合は、Microsoft .NET Framework Registration Correction Tool を使用して問題を解決できます。

    Microsoft .NET Framework 2.0 Registration Correction Tool
    Microsoft .NET Framework Registration Correction Tool は、"原因" セクションに記述されている問題を両方とも解決します。
    次のファイルを Microsoft ダウンロード センターから入手できます。

    Microsoft .NET Framework 2.0 Registration Correction Tool パッケージを今すぐダウンロードしてください。 http://www.microsoft.com/downloads/details.aspx?FamilyID=0BA6038C-061E-4B4A-9BE9-96A323701260&displaylang=ja

    Microsoft ダウンロード センターには、.NET Framework 2.0 がサポートする各プロセッサ アーキテクチャ (x86、x64、および IA-64) にそれぞれ対応するバージョンのツールが用意されています。ほとんどのお客様は 32 ビット バージョンのオペレーティング システムを利用しています。したがって、このような方はこのツールの x86 バージョンをダウンロードしてインストールする必要があります。
    管理者は、/q コマンド ライン スイッチまたは /quiet コマンド ライン スイッチを渡すことにより、このユーティリティをスクリプト内で使用することもできます。この方法により、ユーザー インターフェイスもブロック スクリプトも使用することなく、サイレント モードでアプリケーションを実行できます。
    このツールは、%TEMP%\dd_clwireg.txt フォルダに実行中のログを書き込みます。このログでは、ツールが行っている処理の詳細な情報を確認できます。

    メモ
    - Microsoft .NET Framework Registration Correction Tool は、.NET Framework の現在の任意のバージョンで使用できるように設計されています。
    - このユーティリティを実行するには管理者である必要があります。

    2.1.2 Windows XP または Windows Server 2003 から Windows Vista (RTM) にアップグレードすると、.NET Framework 3.5 の一部のコンポーネントがコンピュータ上に存在しなくなる

    Windows XP または Windows Server 2003 から Windows Vista (RTM) にアップグレードすると、.NET Framework 3.5 の一部のコンポーネントがコンピュータ上に存在しなくなります。

    この問題を解決するには

    1. コントロール パネルを開き、[プログラムと機能] をクリックします。

    2. .NET Framework 3.5 をアンインストールします。

    3. Visual Studio 2008 DVD または http://go.microsoft.com/fwlink/?LinkID=96339 から .NET Framework 3.5 を再インストールします。

    2.1.3 .NET Framework 3.5 SP1 をインストールする前に Windows Update サービスを有効にする

    Windows Vista および Windows 2008 Server で .NET Framework 3.5 SP1 セットアップが失敗し、1058 エラー コードが表示されます。

    この問題を解決するには

    .NET Framework 3.5 SP1 を Windows Vista または Windows 2008 Server にインストールする前に、Windows Update サービスが有効になっていることを確認します。

    2.1.4 .NET Framework 3.5 SP1 Language Pack を Windows 2008 Server にインストールできない

    .Windows 2008 Server では、オペレーティング システムにインストールされている Language Pack が一致しない場合、NET Framework 3.5 SP1 Language Pack をインストールできません。

    この問題を解決するには

    .NET Framework 3.5 SP1 をインストールする前に、一致する Language Pack をオペレーティング システムにインストールします。  オペレーティング システムの Language Pack は、http://www.microsoft.com/Downloads/details.aspx?FamilyID=e9f6f200-cfaf-4516-8e96-e4d4750397ff&displaylang=ja からダウンロードできます。

    2.2. アンインストール

    既知の問題はありません。

    2.3 製品の問題

    2.3.1 一般的な問題

    2.3.1.1 Windows Communication Foundation (WCF) クライアントまたはサービスで、受信メッセージの To ヘッダーの署名を予期しないときに、誤解を招く暗号化の例外がスローされる

    次の状況が当てはまる場合...
    - WCF クライアントまたはサービスに、セキュリティ モード = TransportWithMessageCredentials のバインディング、および共通キー ベースの保証サポート トークン (共通キーにより発行されたトークンなど) が設定されている。
    - サービスまたはクライアントで、次の例のように To ヘッダーが署名され、Signature 要素の TimeStamp 要素の後で参照されるメッセージを受信した場合。

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

     

    ...次の例外がスローされます。


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


    署名の '#To' URI を解決してダイジェストを計算できません。

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


    この問題を解決するには
    To ヘッダーに署名しないでください。

    2.3.1.2 Windows Vista でアセンブリ キャッシュ ビューアを実行する

    アセンブリ キャッシュ ビューア (Shfusion.dll) は Windows のシェル拡張機能であり、この機能により、Windows エクスプローラでグローバル アセンブリ キャッシュの内容を表示および操作できます。Shfusion.dll は、%windir%\Microsoft.NET\Framework\v2.0.50727 ディレクトリにあります。

    Windows Vista では、昇格されたアクセス許可を使用した場合、アセンブリ キャッシュ ビューアは動作しません。昇格されたアクセス許可を持つユーザーがコマンド プロンプト ウィンドウから起動する場合も同様です (たとえば、グローバル アセンブリ キャッシュのパスで START コマンドを使用した場合)。これは、アセンブリ キャッシュ ビューアは Windows エクスプローラのシェル拡張機能であり、昇格されたアクセス許可では動作しないためです。

    この問題を解決するには

    Shfusion.dll は表示のみに使用します。

    更新の場合は、管理者特権を持つコマンド プロンプト ウィンドウを開き、.NET Framework SDK の Gacutil.exe コマンド ライン ツールを使用します。

    2.3.1.3 ASMX サービスの戻り値または出力値で、内部セッターを持つプロパティが null になる

    ASMX Web サービスの既知の問題 この問題を解決するには
    回避策 :

    2.3.2 Windows Communication Foundation (WCF)

    2.3.2.1 特定のトランスポートで Windows 認証を使用したときの認証エラー

    WCF では、現在 Windows 認証のシナリオで既定のドメイン ターゲット名を指定するようになっています。次の状況では、アップグレード時にクライアントに認証エラーが示される場合があります。 この認証エラーの例として "System.ComponentModel.Win32Exception 対象のプリンシパル名が間違っています" があります。
    この問題を解決するには
    クライアントは、SpnEndpointIdentity クラスのサーバーのサービス プリンシパル名か、UpnEndpointIdentity クラスのユーザー プリンシパル名を指定した後に、EndpointAddress に ID を渡すことによって、既定のドメイン ターゲット名を上書きする必要があります。クライアントが Https を使用し、X509CertificateEndpointIdentity を必要とする場合でも、クライアントは SpnEndpointIdentity または UpnEndpointIdentity を指定する必要があります。X509CertificateEndpointIdentity によって、拇印の検証が有効になります。クライアントは、System.Net.ServicePointManager.ServerCertificateValidationCallback に対して登録し、サムプリント検証を手動で実行することで、検証が行われない問題を回避することができます。

    2.3.2.2 SspiNegotiatedOverTransport 認証モードの互換性に影響する変更点

    SecurityMode = TransportWithMessageCredential および Windows のクライアント資格情報タイプで WSHttpBindingWS2007HttpBinding、または NetTcpBinding を使用する場合、以前は NTLM によって認証されたクライアントでサービスに対する認証ができなくなり、次のエラーが示されるようになっています。

    "System.ComponentModel.Win32Exception: セキュリティ サポート プロバイダ インターフェイス (SSPI) ネゴシエーションが失敗しました。サーバーが ID 'host/<hostname>' のアカウントで実行されていない可能性があります。サーバーがサービス アカウント (ネットワーク サービスなど) で実行されている場合は、そのアカウントの ServicePrincipalName をサーバーの EndpointAddress で ID として指定してください。サーバーがユーザー アカウントで実行されている場合は、そのアカウントの UserPrincipalName をサーバーの EndpointAddress で ID として指定してください。"

    このエラーは、サービスが 'host/<hostname>' 以外の ID のアカウントで実行されているときに表示されます。この問題は、SspiNegotiatedOverTransport 認証モードを指定する CustomBindings にも当てはまります。

    この問題を解決するには
    できれば、サービスの ID を指定する UPN または SPN エンドポイント ID を使用してクライアントを更新し、Kerberos 認証が行われるようにします。次の構成スニペットは、UPN でこれを行う方法を示しています。SPN の場合も同様ですが、代わりに <servicePrincipalName> 要素を使用します。

    <system.serviceModel>

    <client>

    <endpoint>

    <identity>

    <userPrincipalName value="user@domain" />

    </identity>

    </endpoint>

    </client>

    </system.serviceModel>

    さらに、SslStreamSecurityBindingElement でスタックに SspiNegotiatedOverTransport が指定された NetTcpBinding または CustomBindings を使用するクライアントは、サービスの証明書の CN チェックを実行するために、コードにカスタム IdentityVerifier を指定する必要があります。次のコード スニペットはこの方法を示すもので、IdentityVerifier の実装の開始点になります。

    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 パスの結合操作で、Expression Blend に不要なポイントが生成される

    Expression Blend でパスの結合操作 ([合算]、[除算]、[交差]、[減算]、および [重複部分を除外]) を使用すると、結合結果に必要以上のパス ポイントが作成されることがあります。

    この問題を解決するには

    この問題の詳細については、こちらを参照してください。

    2.3.4 Windows Workflow Foundation (WF)

    既知の問題はありません。

    3. 関連するリンク

    Visual Studio リリース ノート
    Visual Studio Express Edition リリース ノート


    (C) 2008 Microsoft Corporation.All rights reserved. 使用条件 | 商標 | プライバシーに関する声明