Microsoft Visual Studio 2005 既知の問題

Visual Studio 2005 の最終バージョンを使用して、現在のコンピュータ上の Visual Studio のインストール場所とは異なる場所でコンピュータ上に最後に読み込まれた Beta 2 の VC++ プロジェクトを開いた場合、またはプロジェクトのパスが変更されている場合に、エラーが発生することがあります。

この問題を解決するには

プロジェクト設定ファイルを編集します。ソリューション エクスプローラで淡色表示されたプロジェクト ノードを右クリックし、[<プロジェクト名>.vcproj の編集] をクリックすると、XML エディタにファイルが表示されます。InheritedPropertySheets タグの値を "$(VCInstallDir)VCProjectDefaults\UpgradeFromVC70.vsprops" に変更し、プロジェクトを再読み込みします。

Windows 2000 では、アプリケーション検証ツールをサポートしていません。

この問題を解決するには

Windows XP 以降にアップグレードします。

ユーザーは [オプション] ダイアログ ボックスで、Visual Studio で Windows のローカル言語を使用するように設定できます。 ただし、この設定は分散システム デザイナのツールボックスをリセットするまで反映されません。

この問題を解決するには

1) すべての分散システム デザイナ (アプリケーション デザイナ、システム デザイナ、論理データセンター デザイナ、配置デザイナ) を閉じます。
2) ツールボックス内で右クリックし、[ツールボックスのリセット] をクリックします。
3) 使用する分散システム デザイナを再度開きます。

アプリケーション ダイアグラムで Web サービス プロバイダ エンドポイントが選択されているときに F1 キーを押しても、関連するヘルプ トピックは見つかりません。

この問題を解決するには

ヘルプで「方法 : ASP.NET Web サービスの操作を定義する」を検索してください。

カスタム設定の中、または SDM (System Definition Model) ドキュメント (.sdm ファイルや .ad ファイルなど) でセキュリティ保護された設定として定義されていない設定の中に格納された機密情報は、プレーンテキスト形式でこれらのファイル内に置かれます。

この問題を解決するには

設定および制約エディタを使用する際、SDM ドキュメントでセキュリティ保護された設定として指定されている設定には機密情報を格納できますが、それ以外の設定には機密情報を格納しないでください。詳細については、ヘルプの「方法 : アプリケーション、サーバー、エンドポイント、およびゾーンのカスタム設定を作成する」、および「アプリケーションの実装に関する考慮事項」を参照してください。

Itanium (IA64) にツールをインストールしたときに、Itanium (IA64) ネイティブ ツールのコマンド プロンプトを起動するためのショートカットは作成されません。

この問題を解決するには

Itanium (IA64) ネイティブ ツールのコマンド プロンプトを起動するには、以下の手順を実行します。
1) [スタート] メニューの [ファイル名を指定して実行] をクリックします。
2) cmd と入力します。
3) コマンド プロンプトで、「<Visual Studio 2005 のインストール ディレクトリ>\VC\bin\vcvars64.bat」と入力します。

Visual Studio の既定の設定で、ネットワーク共有のインストルメント化されたバイナリを実行すると、未処理の例外が発生します。

この問題を解決するには

プロファイリングするプロジェクトまたはバイナリをローカル ハード ドライブにコピーまたは移動します。

IIS 5.1 を対象とするアプリケーションのトレース プロファイリング、および ETW イベントの収集の有効化によって、UI で障害が発生し、コマンド ラインに誤った Error VSP1432 が報告されます。

IA64 プロファイリングはサポートされなくなりました。

スタンドアロンのプロファイラのインストールでコード カバレッジを実行しようとすると、未処理の例外が発生します。

ASP.NET プロジェクトに対する単体テストの実行時に、テスト エンジンは web.config ファイルを変更する必要があります。場合によっては、これらのファイルがクリーンアップされず、以降のテスト実行時およびアプリケーション実行時に例外が発生する可能性があります。

この問題を解決するには

テスト実行時に作成されたバックアップから、元の web.config ファイルを復元します。

Windows 98 でアプリケーションを実行する場合は、Windows フォームの ReportViewer コントロールの機能が制限されます。このコントロールを使用して表示できるのは、SQL Server 2005 Reporting Services のレポート サーバー上で以前に発行されたレポートだけです。このコントロールを使用して、ローカル処理モードでクライアントのレポート定義 (.rdlc) ファイルを表示することはできません。

IIS ワーカー プロセスが SYSTEM として実行されている場合、ASP.NET のコード カバレッジ データの収集は機能しません。 IIS ワーカー プロセスの名前は IIS のバージョンごとに異なるため、システム上のワーカー プロセスの名前を MSDN で確認してください。タスク マネージャを使用すると、ワーカー プロセスを実行しているユーザーを確認できます。
メモ : コード カバレッジが無効になっていれば、単体テストは正しく実行されます。

この問題を解決するには

SYSTEM として実行しないように IIS ワーカー プロセスを変更します。

フォーム認証を有効にした状態で ASP.NET アプリケーションをプロファイリングしようとすると、Web サイト構成エラーが発生し、アプリケーションを実行できなくなります。

この問題を解決するには

既知の解決策はありません。

たとえば、デバッガの実行中にシステム デザイナでシステム ダイアグラムにアプリケーションを追加すると、Visual Studio が応答しなくなります。

この問題を解決するには

分散システム デザイナのダイアグラムに対してアクションを実行する前に、コードの実行を停止してください。

共有 dll があり、トレース プロファイリングする場合、その dll を使用しているすべてのプロセスをプロファイリングすることになります。

この問題を解決するには

1) vsperfcmd -proccessoff:PID を使用して、プロファイリングする必要のない各プロセスのプロファイリングを無効にします。
2) HKCU/software/microsoft/visual studio/8.0/VSPERF/Monitor/Settings/ProcessProfile=Off を設定してから、ターゲット プロセスを開始します。その後で vsperfcmd -processon:PID を使用し、プロファイリングの対象とするすべてのプロセスについてプロファイリングを有効にします。
メモ : プロファイリングを終了した後は、モニタをシャットダウンしてデータをレポート ファイルにフラッシュするために、該当する共有 dll を使用しているすべてのプロセスを終了する必要があります。 

NGEN のイメージをインストルメントしようとすると、誤った VSP1014 エラーが報告されます。
CLR は、既に NGEN であるインストルメント化されたマネージ バイナリを読み込みません。

この問題を解決するには

NGEN のイメージではなく、マネージ バイナリ自体をインストルメントしたら、次のいずれかを実行する必要があります。

1) CLR がインストルメント化されたバイナリを使用するように、NGEN のイメージを削除します。
または
2) ngen.exe を使用してバイナリを再生成します。

vsperf.h で提供される MarkProfile、CommentMarkProfile、または CommentMarkAtProfile を使用する場合、プロファイラ モニタを実行していないとアプリケーションがクラッシュします。これは、API に対する呼び出しを追加し、プロファイラではなくデバッガでそれらの呼び出しを起動した場合に、最も顕著に発生します。

この問題を解決するには

"vsperfcmd -start:sample -output:foo.vsp" を使用してプロファイラ モニタを起動します。

次のすべての条件に当てはまる場合、クラス ダイアグラムに参照アセンブリ内の型を表示することはできません。
1. クラス ダイアグラムが Web プロジェクトに含まれている。
2. 参照アセンブリがグローバル アセンブリ キャッシュ (GAC: Global Assembly Cache) にインストールされている。
3. 参照アセンブリが Framework のルート ディレクトリ ("Microsoft.Net\Framework\<バージョン>\") にインストールされていない。

この問題を解決するには

Web プロジェクト以外のプロジェクトから参照型を表示します。

Web サイト内でホストされたインストルメント化されたマネージ ユーザー コントロールは、.NET の既定のセキュリティ設定では読み込むことができません。

この問題を解決するには

ローカル Web サイトの [完全な信頼] を有効にして、インストルメント化された dll を読み込めるようにする必要があります。
caspol.exe -ag 1.2 -url http://localhost FullTrust

アプリケーション検証ツールは、[デバッグ] メニューで選択できる場合でも、混合モードのアプリケーションでは有効になりません。

この問題を解決するには

アプリケーション検証ツールを使用せずにデバッグを続行します。

プロファイラ ドライバでは、初めて使用されるときにドライバ自体の初期化処理を実行する必要があります。この初期化処理がリモート デスクトップ セッションを通じて Windows Server 2000 上で行われた場合、ドライバの初期化はそれ以降のセッションには反映されますが、現在のセッションには反映されません。現在のセッションでモニタを起動しようとすると、Error VSP1398 が発生し、モニタを起動できません。

この問題を解決するには

次のいずれかの方法を実行します。

1) コンピュータを再起動します。
または

2) リモート デスクトップを使用して、同じコンピュータの別のセッションに接続します。

ユーザーを "Controller users" グループに追加しても "Controller admin" グループには追加しなかった場合、その変更はコントローラ サービスを再起動するまで有効になりません。このため、そのユーザーはコントローラに接続できません。

この問題を解決するには

コントローラ サービスを再起動します。

Visual Studio 2005 では、ファイルの再読み込み時にエンコーディングの変更は検出されません。現在のエディタ外部のファイルのエンコーディングを変更した場合、またはエディタで開いているファイルを変更するソース管理操作を実行した場合に、Visual Studio はファイルを自動的に再読み込みします。エディタでファイルの内容が再読み込みされた後、正しく表示されない場合があります。

この問題を解決するには

1. 変更を保存せずにファイルを閉じます。
   
2. [ファイル] メニューの [開く] をクリックし、[ファイル] をクリックします。
   
3. [ファイルを開く] ダイアログ ボックスで、[開く] の横の矢印をクリックし、[ファイルを開くアプリケーションの選択] をクリックします。
   
4. [ファイルを開くアプリケーションの選択] ダイアログ ボックスの一覧で、ファイルを開くエディタ (バイナリ エディタ、リソース エディタなど) を選択します。特定のエンコーディングでファイルを開くには、XML Editor with Encoding など、エンコーディングをサポートするエディタを選択します。
   
5. [OK] をクリックします。
   
6. [エンコード] ダイアログ ボックスで、[エンコード] ドロップダウン リストから適切なエンコーディングを選択します。
   
7. [OK] をクリックします。
   

Visual Studio 2005 の後に Visual Studio .NET 2003 をインストールした場合、いずれかのバージョンの Visual Studio からセットアップ プロジェクトをビルドすると製品の修復が発生します。製品の修復は、Visual Studio .NET 2003 をインストールしたユーザー以外のユーザーに対してのみ発生します。

この問題を解決するには

製品の修復が発生したとき、そのまま続行して完了させます。ただし、修復が正常に終了するには、Visual Studio .NET 2003 のインストールを実行したユーザー以外の、管理者特権を持つユーザー アカウントで実行する必要があります。

Reg-Free COM コンポーネントを含む Visual Studio 2005 Tools for Microsoft Office アドイン プロジェクトをインストールすると、アドインの対象となる Office 製品を実行できなくなります。 

この問題を解決するには

Reg-Free COM は、Visual Studio 2005 Tools for Microsoft Office アドイン プロジェクトではサポートされていません。

署名が有効になっている Visual Studio .NET 2003 からインポートしたセットアップ プロジェクトと配置プロジェクトは、Visual Studio 2005 でのビルド時に署名されません。ビルド時に、"ファイル ' <filename> ' は署名されていません。配置プロジェクトには使用できないプロパティの署名が含まれています。詳細については、ヘルプを参照してください。" というメッセージが [エラー一覧] ウィンドウに表示されます。

この問題を解決するには

署名を有効にするには、セットアップ/配置プロジェクトのビルド後の手順のビルド出力で、ソフトウェア開発キット ツールの SignTool を起動します。これを実行する方法の詳細については、上記のビルド メッセージに関連するヘルプ トピックを参照してください。ヘルプにアクセスするには、[エラー一覧] ウィンドウでメッセージを強調表示し、F1 キーを押します。

プロジェクトの不要になった署名プロパティを削除するには、以下の手順を実行します。
1. [エラー一覧] ウィンドウでメッセージをダブルクリックします。
2. 表示されるダイアログ ボックスの [はい] をクリックします。これで、プロジェクトの不要になった署名プロパティがプロジェクト ファイルから削除されます。

Visual Studio 2005 で使用できる .NET Framework 2.0、SQL Server 2005 Express、Microsoft Visual J# 再頒布可能パッケージ、Windows Installer 2.0、および Windows Installer 3.1 用のブートストラップ パッケージは、32 ビット プラットフォームだけを対象としています。これらのパッケージに組み込まれたブートストラップを 64 ビット プラットフォームで実行した場合、インストールがブロックされることがあります。

この問題を解決するには

64 ビット バージョンの .NET Framework 2.0 および SQL Server 2005 Express 用の再頒布可能なブートストラップ パッケージは、Microsoft ダウンロード センターで入手できます。

[設定としてユーザー定義された型] を使用すると、UDT が含まれるアセンブリを使用するプロジェクトを開いているときにそのアセンブリを更新した場合、問題が発生することがあります。このシナリオが必要な場合は、UDT アセンブリでインクリメンタル バージョン セマンティクスを使用することで、この問題を回避できます。

この問題を解決するには

設定として使用するユーザー定義型がクラス ライブラリに存在する場合、ライブラリをインクリメンタル方式でバージョン化して問題を軽減します。ユーザー定義型が EXE 内に存在する場合は、IDE を閉じ、再起動して UDT への変更を有効にする必要があります。

My.Forms は、ユーザー コントロール プロジェクトでは使用できません。

この問題を解決するには

既知の解決策はありません。

リモート コンピュータで次のコードを実行しているとき、実行中のコードにリモート デバッグで接続し、Sleep() 呼び出しの内部で実行を中断したとすると、変数 c のメンバを評価することはできません。

c = New c1     'c1 は有効なクラスであることが前提
While True
Threading.Thread.Sleep(1000)
End While

この問題を解決するには

Sleep() からステップ アウトすると、通常どおりオブジェクトを評価できるようになります。

ロード テストの結果ビューのエラー テーブルに、"しきい値の規則を適用するために必要とされる依存カウンタが見つかりませんでした" というメッセージと共にエラーが表示されます。ロード テストには、あるパフォーマンス カウンタを別のパフォーマンス カウンタと比較するしきい値の規則が含まれています。このエラーは、サンプリング間隔中に比較パフォーマンス カウンタによってインスタンスが生成されない場合に発生します。

この問題を解決するには

関連付けられたしきい値の規則を変更して、別のパフォーマンス カウンタではなく定数と比較するようにします。これは、指定したしきい値の規則を実行できない点を除き、ロード テストの結果に影響を及ぼすことはなく、安全に無視できます。

カウンタを変更するには、以下の手順を実行します。
1. ロード テストを編集し、[カウンタ セット]、[ロード テスト]、[カウンタ カテゴリ]、[LoadTest:Request]、[カウンタ]、[Avg. Connection Wait Time]、[しきい値規則] の順にクリックします。
2. カウンタの比較規則を削除します。
3. 右クリックしてカウンタの比較規則を追加します。
4. この規則で、[しきい値を超えたときに警告] を true に設定し、警告を .01 (10 ミリ秒)、重大なしきい値を .02 (20 ミリ秒) に設定します。

未使用のデータ ソースが含まれたコード化された Web テストを実行すると、"オブジェクトのインスタンスに設定されていないオブジェクトです。" というエラーが発生し、テストが失敗します。このエラーが発生するのは、コード化された Web テスト内でデータ ソースが定義されているにもかかわらず、テストでデータ ソースがどのアイテムにもバインドされないためです。

この問題を解決するには

コード化された Web テストから未使用のデータ ソースを削除するか、DataBinding 属性をテスト クラスに追加することにより、テストでデータ ソースのフィールドをアイテムにバインドします。

Web サービスを呼び出す単体テストを含んだロード テストを実行する場合、単体テストのコードでは、System.Web.Services.Protocols.SoapHttpClientProtocol を実装する Web サービス プロキシ クラスの Proxy プロパティを明示的に設定する必要があります。プロキシを自動的に検出する必要がある場合はパフォーマンスのボトルネックが生じる可能性がありますが、Proxy を明示的に設定すると、この問題を防ぐことができます。

たとえば、次のような Web サービス プロキシ クラスがあるとします。

[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.ComponentModel.DesignerCategoryAttribute("code")]
[System.Web.Services.WebServiceBindingAttribute(Name="InstantOrderSoap", Namespace="http://tempuri.org/")]
public partial class InstantOrder : System.Web.Services.Protocols.SoapHttpClientProtocol {

}

プロキシ オブジェクトを作成した後、そのオブジェクトを使用する前に、Proxy プロパティを次のように明示的に設定します。

InstantOrder orderCheck = new InstantOrder();
orderCheck.Proxy = new WebProxy("myproxy", true);

Windows 98 では、ActiveX EXE オブジェクトのバリアント プロパティに構造体を渡すことはできません。クリーンな Windows 9X コンピュータでは、System DLL rpcrt4.dll が既定で登録されていないため、オペレーティング システムに登録キー [HKEY_CLASSES_ROOT\CLSID\{B5866878-BD99-11D0-B04B-00C04FD91550}] がないことが問題です。登録が見つからないため、呼び出しが失敗します。

この問題を解決するには

C:\Windows\System に移動し、RegSvr32.exe rpcrt4.dll を手動で呼び出します。

コンソール アプリケーションに以下のコードを貼り付けると、アプリケーションがハングします。

Class C1(Of U As U)    'この循環制約によって後で問題が生じる
End Class

Partial Class C1(Of U)
Dim x As New U        '問題 ? これが原因で無限ループが発生し、メモリを使用できなくなるまでメモリ使用量が増え続ける

End Class

この問題を解決するには

循環制約を削除します。

ClickOnce を使用してアプリケーションを起動した場合、StartupNextInstanceEvent に対するパラメータに、アプリケーションの 2 つ目のインスタンスに対するコマンド ライン引数が含まれません。My.Application.Deployment.ActivationUri プロパティを使用して、コマンド ライン引数を取得する必要があります。

この問題を解決するには

次のように、ASP ランタイム クラスを使用してコマンド ライン引数を取得します。

Imports System.Web

Dim commandLineArgs as NameValueCollection = _
HttpUtility.ParseQuery(My.Application.Deployment.ActivationUri)

<Assembly: InternalsVisibleTo("Foo.Dll, PublicKeyToken=a29c01bbd4e39ac5")>

この属性は Friend 型を他のアセンブリに公開します。この属性は、Visual Basic コンパイラではサポートされていません。

プライベート型をテストするためにこの属性に依存する一部の単体テスト テクノロジは、期待どおりに動作しません。

この問題を解決するには

既知の解決策はありません。

一般的なユーザー シナリオについて説明する vsperfcmd のドキュメントはありません。

vsperfcmd.exe と共に使用する一般的なコマンドの例を次に示します。
vsperfcmd -start:sample -output:foo.vsp
vsperfcmd -start:trace -output:foo.vsp -counter:g,1,0,InstructionsRetired
vsperfcmd -launch:foo.exe -args:"input arguments" -gc:lifetime
vsperfcmd -attach:foo.exe -pf:1

VB Web コントロール ライブラリ プロジェクトでは、My.Log は使用できません。 My はプロジェクト単位であるため、My.Log は Web サイト プロジェクト内の WebUserControls では使用できますが、Web サイトで使用される Web コントロール ライブラリ プロジェクト内のクラスでは使用できません。

この問題を解決するには

My.Log のメソッドの代わりに Trace.Write を使用します。

1) 次のコードによって新しいコンソール アプリケーションを作成します。

    My.Application.Log.DefaultFileLogWriter.CustomLocation = "D:\temp"
    My.Application.Log.WriteEntry("Foo")

2) アプリケーションを実行します。

結果 :
ログ ファイルは D:\temp に作成されますが、ディレクトリ D:\Documents and Settings\<ユーザー名>\Application Data\Microsoft\WindowsApplication1\1.0.0.0 が存在しない場合、このディレクトリも作成されます。ユーザーにこれを実行するためのアクセス許可がない場合、例外がスローされます。既定では、ASP.NET プロセスには Application Data ディレクトリへの書き込みアクセス許可がないため、Web アプリケーションでクラス ライブラリを使用したときに、この例外が発生する可能性が高まります。

この問題を解決するには

1) app.config を使用して既定の FileLogTraceListener を削除し、別の TraceListener を使用するよう My.Application.Log を再構成します。
2) 未処理の例外イベントを待機し、イベントが発生したら続行します。
3) すべてのログ呼び出し (または、最低でも初めて実行されたと考えられるログ呼び出し) を試行/キャッチします。

既存の COM コンポーネントのほとんどは 32 ビット プラットフォーム上でのみ使用でき、64 ビット プラットフォーム上の 64 ビット プロセスでは動作しません (ただし、64 ビット プラットフォーム上の 32 ビット プロセスでは正しく動作します)。このような 32 ビット COM コンポーネントを参照する Visual Basic アプリケーションおよび C# アプリケーションは、既定では 64 ビット プラットフォーム上では動作しません。これは、既定ではアプリケーションが 64 ビット プロセスとして起動するためです。

1 つ以上の COM 参照を含むプロジェクトが次のような場合にこの問題が発生します。
1. Visual Studio 2005 に移行され、64 ビット プラットフォーム上で実行された場合

または
2. 64 ビット プラットフォーム上で Visual Studio 2005 を使用して作成された場合

Visual Studio 2005 では、VB コンパイラと C# コンパイラは、プラットフォーム ターゲット プロパティを使用して、.exe または .dll を 32 ビットと 64 ビットのどちらの CPU アーキテクチャ モードで実行する必要があるかを判断します。Visual Studio 2005 では、このプロパティが既定で "AnyCPU" に設定されています。これは、ホスト プラットフォームに応じて、アプリケーションを 32 ビット モードと 64 ビット モードのどちらのモードででも実行できることを示しています。この場合、これらのアプリケーションをデバッグまたは実行しようとすると、"クラスをインスタンス化できません..." などのメッセージが表示される場合があります。

この問題を解決するには

COM コンポーネントを参照する Visual Basic プロジェクトまたは C# プロジェクトのプラットフォーム ターゲット プロパティに "X86" を設定します。

C# プロジェクトの場合 :
1.    ソリューション エクスプローラでプロジェクトを右クリックし、[プロパティ] を開きます。
2.    [ビルド] タブをクリックします。
3.    [プラットフォーム ターゲット] プロパティに「X86」を設定します。

VB プロジェクトの場合 :
1.    ソリューション エクスプローラでプロジェクトを右クリックし、[プロパティ] を開きます。
2.    [コンパイル] タブをクリックします。
3.    [詳細コンパイル オプション] をクリックします。
4.    [ターゲット CPU] プロパティに「X86」を設定します。

Express Editions :
Visual Basic 2005 Express Edition および Visual C# 2005 Express Edition では、開発環境内でターゲット プロパティが公開されていません。プロジェクト ファイルを変更するには、テキスト エディタまたは XML エディタを使用して注意しながら変更する必要があります。
1.    プロジェクトまたはソリューションを閉じます。
2.    [ファイル] メニューの [ファイルを開く] をクリックします。
3.    プロジェクト ディレクトリに移動し、プロジェクト ファイルを強調表示します。
4.    [開く] をクリックし、XML エディタでプロジェクト ファイルを開きます。
5.    最初の <PropertyGroup> セクションを探し、次の行を追加します。
<PlatformTarget>x86</PlatformTarget>
1.    プロジェクト ファイルを保存します。
2.    [ファイル] メニューの [プロジェクトを開く] または [ソリューションを開く] を使用して、プロジェクトまたはソリューションを再度開きます。
3.    開発、デバッグ、テストを続行します。

また、アプリケーションが 64 ビット プラットフォームを対象としている場合は、アプリケーションに追加する COM コントロールの 64 ビット対応版を開発用コンピュータと配置用コンピュータに置くことができます。

Visual Studio 製品ファミリのいずれかを Windows 移動プロファイルと共に使用すると、セッションを起動するたびに、"Visual Studio 2005 は最初の使用のために環境を構成中です。数分間お待ちください。" という初めての起動であることを示すメッセージが表示される場合があります。これにより、起動時のパフォーマンスが不必要に低下する可能性があります。

この問題を解決するには

[ツール] の [オプション] をクリックします。[設定のインポートとエクスポート] をクリックし、[このファイルに自動的に設定を保存する:] に指定したパスを "My Documents" ディレクトリの下ではないパスに変更します。

Visual Studio 2005 をインストールした後に、OnConnection で DTE.CommandBars の取得を試みるアドインをインストールした場合、Visual Studio 2005 を初めて起動したときに次のメッセージが表示されます。

    アドイン <アドイン名> の読み込みに失敗したか、または例外が発生しました。
    このアドインを削除しますか?

この問題を解決するには

Visual Studio 2005 をインストールする場合、インストール後に Visual Studio を起動し、アドインをインストールする "前" に Visual Studio を再度シャットダウンします。
このアドインが既にインストールされているときに、上記のメッセージが表示された場合は、[いいえ] をクリックし、Visual Studio を閉じます。コマンド プロンプトで、<VSInstallDir>\Common7\IDE に移動し、次のコマンドを実行します。
    devenv /resetaddin *

このシナリオでは、Visual Studio ソリューションに Web サービスへの Web 参照を含む Visual Basic または Visual J# のクラス ライブラリが含まれます。また、ソリューションには、このクラス ライブラリを参照する ASP.NET Web サイトも含まれます。これらのアイテムをソリューションに追加したら、構成ファイルの一部のエントリを、クラス ライブラリの App.config ファイルから Web サイトの Web.config ファイルにコピーする必要があります。構成ファイルのエントリをコピーした後、アプリケーション ダイアグラムを追加してこれらのアイテムをリバース エンジニアリングする前にクラス ライブラリをビルドした場合、ASP.NET Web サイトだけがダイアグラムでリバース エンジニアリングされる可能性があります。したがって、Web サービス参照は、ASP.NET アプリケーションの Web サービス コンシューマ エンドポイントとしてリバース エンジニアリングされず、参照先 Web サービスへの接続がリバース エンジニアリングされないことがあります。ダイアグラム上にまだ存在しない Web サービスの Web 参照の場合、参照先 Web サービスの外部 Web サービスがリバース エンジニアリングされない場合があります。

この問題を解決するには

1. アプリケーション ダイアグラムを追加した後で、クラス ライブラリ内の Web 参照を右クリックし、[Web 参照の更新] をクリックします。
2. クラス ライブラリを再度ビルドします。

実行時にテーブルの場所を別のデータベースに変更する場合は、新しいデータベース内のテーブルと元のレポート内のテーブルを同じ名前にする必要があります。テーブル名が一致しない場合、接続は失敗します。

この問題を解決するには

新しいデータベースに元のレポート内のテーブルと同じ名前のテーブルが含まれていることを確認します。

レポート内のすべてのレコードを表示するようにビューアの選択数式を設定する場合は、null 文字列ではなく空の文字列を使用する必要があります。null 文字列は、元のレポート選択数式をオーバーライドできません。

この問題を解決するには

空の文字列は "" または String.Empty で表します。null 文字列は C# では null、Visual Basic では Nothing で表します。

Visual Studio .NET 2002 または Visual Studio .NET 2003 から Visual Studio 2005 に移行した ASP.NET Web アプリケーションでは、Shift-JIS としてエンコードされた日本語は正しく表示されません。

この問題を解決するには

移行前に、すべての ASP ページを UTF-8 に変換します。

Crystal Reports 9 または Crystal Reports 10 の Windows プロジェクトを Crystal Reports for Visual Studio 2005 に移行すると、CrystalDecisions.ReportSource、CrystalDecisions.Shared、CrystalDecisions.Windows.Forms の各アセンブリへの参照は失われます。

この問題を解決するには

移行後、アプリケーションをコンパイルする前に、参照を手動で追加します。

このシナリオでは、Visual Studio ソリューションに、実装する Windows アプリケーションと ASP.NET アプリケーションを含むアプリケーション ダイアグラムが含まれます。また、ソリューションには、Web サービスへの Web 参照を含むクラス ライブラリも含まれます。Windows プロジェクトと ASP.NET Web プロジェクトは、共にこのクラス ライブラリを参照しています。クラス ライブラリをビルドし、必要なエントリをクラス ライブラリの App.config ファイルから両方のプロジェクトの構成ファイルにコピーした後、Windows アプリケーションまたは ASP.NET アプリケーションの Web サービス コンシューマ エンドポイントとして、Web 参照がリバース エンジニアリングされない場合があります。また、参照先 Web サービスへの接続もリバース エンジニアリングされません。ダイアグラム上にまだ存在しない Web サービスの Web 参照の場合、参照先 Web サービスの外部 Web サービスがリバース エンジニアリングされない場合があります。

この問題を解決するには

1. アプリケーション ダイアグラムを閉じます。
2. Windows プロジェクトと ASP.NET プロジェクトから共有クラス ライブラリへの参照を削除します。
3. クラス ライブラリ参照を ASP.NET プロジェクトに追加します。
4. アプリケーション ダイアグラムを開きます。
5. クラス ライブラリ参照を Windows プロジェクトに追加します。

FTP Web サイトを開き、データ ファイル (MDB または MDF) を App_Data ディレクトリに追加した後に、[サーバー エクスプローラ] ウィンドウを開き、Data Connections ノードの
データ ファイルへの接続を展開した場合、IDE がクラッシュまたはハングする可能性があり、保存していないデータが失われることがあります。

この問題を解決するには

ファイル システムまたは IIS Web サイトを使用して、ローカル ファイルの場所から Web サイトを開発し、[Web サイトのコピー] コマンドを使用して、FTP パスとの間でファイルを転送します。

ユーザーが CrystalReportViewer コントロールからレポートをエクスポートまたは出力したときに、例外がスローされる場合があります。この問題は、Web ページに CrystalReportViewer コントロールと Microsoft Web コントロールが含まれており、Firefox Web ブラウザでページを表示したときに発生します。

この問題を解決するには

ASP ページで EnableEventValidation に False を設定して、ユーザーが Firefox でレポートを出力またはエクスポートできるようにします。

アプリケーション検証ツールは、[デバッグ] メニューで選択できる場合でも、混合モードのアプリケーションでは有効になりません。アプリケーション検証ツールが有効になっておらず、アプリケーション検証ツールを使用せずにデバッグを続行できることを示すダイアログ ボックスが表示されます。

この問題を解決するには

アプリケーション検証ツールを使用せずにデバッグを続行します。

ロード テストの構成が適切であるにもかかわらず、ローカル実行のロード テストの結果が結果データベースに格納されません。この状況が発生すると、次のメッセージが表示されます。
"ロード テストの結果データベースを開けませんでした。テスト コントローラ (またはローカル コンピュータ) の接続文字列で指定されたロード テストの結果データベースが、ロード テスト スキーマを含み、現在使用可能なデータベースを指定していることを確認してください。"
ローカル ロード テストの結果データベースは、最初のローカル ロード テスト実行の初期化中に作成されます。このエラーは、最初のロード テストの実行を開始するユーザーが、データベースを作成できるだけの特権を持っていない場合に発生します。

この問題を解決するには

管理者が最初のロード テストの実行を開始して、ロード テストの結果データベースを強制的に作成する必要があります。

SQL Server Express の構成と Windows ファイアウォールによって、SQL Server Express に格納されたロード テストの結果へのリモート アクセスがブロックされる場合があります。SQL Server Express の既定のインストールでは、データベースへのリモート アクセスは無効になっています。Load Controller のセットアップによって、SQL Server Express の構成と Windows ファイアウォールの構成は SQL Server Express へのリモート アクセスを許可するように設定されます。ただし、セットアップで SQL Server Express をインストールした場合にも、これらの構成変更が行われます。Visual Studio のセットアップでも SQL Server Express をインストールできますが、リモート アクセスを許可するように SQL Server Express と Windows ファイアウォールの構成が自動的に変更されるわけではありません。

ロード テストの結果、ビューアが SQL Server Express に格納されたロード テストの結果にリモート アクセスできない場合、次のメッセージが表示されます。

"結果レポジトリを読み取れませんでした : ロード テストの結果レポジトリにアクセスできませんでした: サーバーへの接続を確立中にエラーが発生しました。SQL Server 2005 への接続時にこのエラーが発生するのは、既定の設定で SQL Server がリモート接続を許可していないことが原因の可能性があります。"

この問題を解決するには

リモート アクセスを許可するよう SQL Server Express と Windows ファイアウォールを手動で構成します。SQL Server Express へのリモート アクセスを有効にするには、以下の手順を実行します。

1. [スタート] メニューで [すべてのプログラム]、[Microsoft SQL Server 2005]、[構成ツール]、[SQL Server 構成マネージャ] の順にクリックして、SQL Server 構成マネージャを開きます。
2. SQL Server 構成マネージャの左ペインで、[SQL Server 2005 ネットワークの構成] のノードを展開し、[SQLEXPRESS のプロトコル] をクリックします。
3. 右ペインで [名前付きパイプ] を右クリックし、[有効化] をクリックします。
4. [TCIP/IP] を右クリックし、[有効化] をクリックします。
5. 左ペインで [SQL Server 2005 のサービス] をクリックします。
6. 右ペインで [SQL Server ブラウザ] を右クリックし、[プロパティ] をクリックします。
7. [プロパティ] ダイアログ ボックスの [サービス] タブをクリックします。
8. [サービス] ページで [開始モード] プロパティを [自動] に設定し、[OK] をクリックします。
9. [SQL Server ブラウザ] を右クリックし、[開始] をクリックします。
10. [SQL Server (SQLEXPRESS)] を右クリックし、[再起動] をクリックします。

Windows ファイアウォールを構成するには、以下の手順を実行します。

1. [Windows ファイアウォール] ダイアログ ボックスを開き、[例外] タブをクリックします。
2. [プログラムの追加] をクリックし、[参照] をクリックして sqlbrowser.exe を検索し、[OK] をクリックします。
3. [プログラムの追加] をクリックし、[参照] をクリックして sqlservr.exe を検索します。[OK] をクリックします。
4. [ポートの追加] をクリックし、[名前] に "SQL Service"、[ポート番号] に "1433" と入力し、[TCP] オプション ボタンをオンにします。
5. [Windows ファイアウォール] ダイアログ ボックスで [OK] をクリックします。

Long (VT_I8) を渡す Windows 2000 または Windows 9x での遅延バインド呼び出しは失敗します。OLE オートメーション経由の VT_I8 でサポートされているプラットフォームは Windows XP だけです。

この問題を解決するには

Long ではなく整数を使用します。

vsWindowKindImmediate 定数は、イミディエイト ウィンドウの正しい GUID を返しません。

この問題を解決するには

vsWindowKindImmediate 定数の代わりに GUID として {ECB7191A-597B-41F5-9843-03A4CF275DDE} を使用します。
また、次のコードによってイミディエイト ウィンドウの正しい GUID を取得することもできます。
    DTE.Windows.Item("Immediate Window").ObjectKind

Office のアドインを実行するには、Extensibility.dll が必要です。これは、共有アドインのセットアップ プロジェクトに自動的に含まれるわけではありません。

この問題を解決するには

ソリューション エクスプローラで、アドイン セットアップ プロジェクトを右クリックし、[追加] - [アセンブリ] をクリックします。[.NET] タブで [機能拡張] をクリックし、[OK] をクリックします。アセンブリを追加したら、ソリューション エクスプローラでそのアセンブリを選択し、[登録] プロパティに「vsdraDoNotRegister」が設定されていることを確認します。

環境設定のリセットは、[ツール] の [設定のインポートとエクスポート] をクリックし、[すべての設定をリセット] を選択することによって実行できます。また、コマンド ウィンドウで "Tools.ImportAndExportSettings /reset" コマンドを実行することでリセットすることもできます。どちらの場合も、Visual Studio を再起動するまでフォントと色のオプションは反映されません。

この問題を解決するには

リセット操作を実行したら、Visual Studio を再起動します。

アプリケーション検証ツールは、次のシナリオではサポートされていません。
1. DLL プロジェクトで [アプリケーション検証ツールを使って開始] を使用し、ソリューションに含まれていない実行可能ファイルにプロジェクトを読み込む場合。
2. [プロジェクトのプロパティ] ? [デバッグ] の [コマンド] を現在読み込まれているプロジェクト ($TargetPath) 以外のものに変更する場合。これは、リモート デバッグにも当てはまります。
3. ATL Web サービス プロジェクトが別のプロセスで実行されているため、アプリケーション検証ツールがこれらのプロジェクトでサポートされていない場合。
4. VC スマート デバイス プロジェクトが別のアーキテクチャで実行されているため、これらのプロジェクトでアプリケーション検証ツールがサポートされていない場合。
アプリケーション検証ツールは、IDE に読み込まれた EXE プロジェクトでのみ有効になります。

この問題を解決するには

上記のシナリオ 1 と 2 の場合、IDE に対象の実行可能ファイルのプロジェクトを読み込み、アプリケーション検証ツールを使用します。上記のすべてのケースでアプリケーション検証ツールを使用した場合、通常のデバッグ セッション ([デバッグ] - [開始]) と同様に動作します。

1.63   Windows プロジェクトと ASP.NET Web プロジェクトが同じクラス ライブラリを参照している場合、そのクラス ライブラリ内の Web サービス参照がリバース エンジニアリングされないことがある 

1.64   Visual Studio 2005 Team Edition for Software Testers : Web テストを実行すると、"オブジェクトのインスタンスに設定されていないオブジェクトです。" というエラーによってテストが失敗する 

1.65   [データ ソース] ウィンドウからフィールドをコピーして貼り付けた後、コントロールの DataBindings プロパティが正しくない 

1.66   SQL Server 2005 と同じマシンに VS をインストールすると、VS で Business Intelligence プロファイルが使用されることがある 

1.67   更新プログラムをインストールしていないコンピュータで共有アドインが読み込まれない 

1.68   C# Express をアンインストールすると、Visual Studio コンテンツ インストーラの実行に失敗する 

1.69   英語以外のバージョンの Windows オペレーティング システムに .addin ファイルをインストールするときに回避策が必要な場合がある 

Visual Source Safe のマージ機能は UTF-8 ファイルの最後が非ASCII テキストの場合、正確に行の最後を判断できません。
コマンドラインツールで"ssexp /merge"と起動した際にも同じ警告ダイアロが表示されます。 コマンドラインツールで UI 操作オプションを付け "ssexp /merge /a" と起動した場合はこの警告ダイアロ表示されません。

この問題を解決するには  

警告ダイアログ "行の終わりの不整合" 上で "はい" を選択します。

Visual Studio 2005 July CTP 日本語版がインストールされたマシンで Windows アプリケーションのプロジェクト ファイルを作成し、その後 Visual Studio 2005 July CTP 日本語版をアンインストールした後、 Visual Studio 2005 製品版をインストールして起動した場合、「最近使ったプロジェクト」に July CTP 版で作成したプロジェクト ファイルが表示されます。そのプロジェクトファイルを選択して開こうとすると"コンポーネント 'System' への参照は、プロジェクトに既に存在します。" というメッセージが表示される場合があります。

この問題を解決するには  

このメッセージが表示された場合は一旦 Visual Studio 2005 製品版を終了し、再起動することでプロジェクト ファイルを使用することが可能になります。

手動テストの実行中には、手動テストの [実行中] ページが表示され、テストの実行が完了すると、手動テストの結果ページが表示されます。手動テストの名前に DBCS 文字が含まれていると、この 2 つのページに手動テストが正しく表示されません。表示内容は、そのテストの HTML が未加工のまま表示されたように見えます。テストの本文を右クリックし、[最新の情報に更新] をクリックすると、テストが数分間ハングした後、空白になります。

この問題を解決するには

Microsoft Word 形式の手動テストの名前には、1 バイト文字セット (SBCS: Single-Byte Character Set) のみを使用します。テストの [説明] プロパティおよびテストの本文では、DBCS 文字を使用できます。

Visual Studio 2005 (x86) および SQL Server 2005 (x86) がインストールされている 64 ビット コンピュータでは、SQLCLR デバッグが失敗します。次のメッセージが表示されます。

---------------------------
Microsoft Visual Studio
---------------------------
.NET コードをデバッグできません。'<Machine Name>' 上の SQL Server プロセスにアタッチできませんでした。64 ビット バージョンの Microsoft Visual Studio リモート デバッグ モニタ (MSVSMON.EXE) を使用して、32 ビット プロセスまたは 32 ビット ダンプをデバッグすることはできません。32 ビット バージョンを使用してください。
---------------------------
OK
---------------------------

コンピュータのオペレーティング システムが 64 ビットであるため、64 ビット バージョンの msvsmon.exe が自動的に起動されます。アプリケーションは共に 32 ビットであるため、32 ビット バージョンを起動する必要があります。これは、現時点では修正できないアーキテクチャ上の問題です。

この問題を解決するには

ローカル コンピュータで SQLCLR デバッグを行う場合は、ユーザーが 32 ビット バージョンの msvsmon.exe を手動で起動します。

32 ビット バージョンの msvsmon.exe を登録して自動的に起動するようにすると、他の 64 ビット デバッグのシナリオを実行できなくなるため、これはお勧めしません。

AuthorizationStoreRoleProvider は承認マネージャに依存しています。承認マネージャから返されるすべてのエラー メッセージが問題の根本原因を示しているとは限りません。既知の誤ったエラー メッセージまたは不明瞭なエラー メッセージを以下に示します。

"COMException (0x8007052b): パスワードを更新できませんでした。現在のパスワードとして指定された値が間違っています。"
このエラーは、アクセス拒否エラーです。ASP.NET が IIS 5.0、Windows XP IIS 5.1、または Windows Server 2003 上の IIS 5.0 分離モード上に配置され、アプリケーションが統合 Windows 認証を使用するように設定され、かつ、ポリシー ファイルが現在の ASP.NET アプリケーションのディレクトリ構造内にあるという条件がすべて満たされた場合に、このエラーが発生する可能性があります。ASP.NET がローカル コンピュータ アカウントとして実行されているときに、リモートの AD インスタンスまたは ADAM インスタンス内のポリシー ストアにアクセスしようとした場合にも、このエラーが発生する可能性があります。

"追加データがあります"
このエラーは、ポリシー ストアが見つからなかったことを意味します。接続文字列が ADAM インスタンスを指しているが、存在しない ADAM パーティションを参照している場合、このエラーが発生する可能性があります。たとえば、接続文字列が "LDAP://localhost:4000/Cn=storename, DC=Partition1" の場合、ADAM インスタンスに Partition1 が存在しないと、このエラーが発生します。

"指定されたサーバーは、要求された操作を実行できません。"
このエラーは、指定されたサーバーが見つからなかったことを意味します。接続文字列が存在しないサーバーを指しているか、AD または ADAM が待機していないポート番号を使用している場合に、このエラーが発生する可能性があります。

"ArgumentException: パラメータが間違っています"
このエラーは、ユーザーがロールに属しているかどうかを確認するために使用する承認マネージャの LDAP クエリ グループが無効であることを示しています。

この問題を解決するには

上記の各エラー状況について、考えられる原因を検討します。アプリケーションの構成が原因の 1 つとして考えられる場合は、上記の情報を基にアプリケーションの構成を変更または修正します。

ASP.NET 2.0 では、SQL Server 2005 Express と統合することにより、ASP.NET 2.0 の新しいアプリケーション サービスの多くで必要とされるデータベースを自動作成できるようになっています。この機能は、対話ユーザーの ID または ASP.NET をホストするワーカー プロセスの ID を使用して実行されるサーバー プロセスの生成を、SQL Server 2005 Express がサポートすることによって実現されています。共有ホスト サーバー上のような信頼性の低い環境では、ASP.NET アプリケーション間で意図しないデータ共有が発生する可能性があるため、SQL Server ワーカー プロセスの生成機能を有効にしないようにする必要があります。

この問題を解決するには

スタンドアロンのインストーラを使用して SQL Server 2005 Express をインストールする場合は、高度なセットアップ オプションを使用することで、ユーザー インスタンス機能のサポートを明示的に無効にできます。

次のように、既存の SQL Server 2005 Express インストールのユーザー インスタンス機能を手動で無効にすることもできます。
1. ローカル ボックス管理者としてログインし、cmd.exe を実行してコマンド ウィンドウを開きます。
2. PATH 環境変数に示されたディレクトリから osql.exe を使用できない場合は、ディレクトリを osql.exe を格納する SQL Server 2005 Express ディレクトリに変更します。
3. SQL Server の親インスタンスに接続します (osql -E -S .\sqlexpress)。
4. 次の SQL コマンドを実行します。
exec sp_configure 'show advanced option', '1'
go
reconfigure with override
go
exec sp_configure 'user instances enabled', 0
     go
reconfigure with override
go

以前のバージョンの ASP.NET では、フォーム認証の永続 Cookie の有効期間は 50 年としてハードコーディングされていました。ASP.NET 2.0 では、フォーム認証の永続 Cookie の有効期限は、現在の日時に構成の "timeout" 属性の値を加えた値に設定されます。既定では、これは永続 Cookie の有効期間が 30 分であることを意味します。有効期間を延長する場合は、"timeout" 属性の値を増やす必要があります。ASP.NET 2.0 では、これは、セッション ベースの Cookie と永続 Cookie の両方に格納されたフォーム認証チケットで新しいタイムアウト値を使用するということです。

この問題を解決するには

永続 Cookie に別のタイムアウト値が必要な場合、開発者は FormsAuthentication.SetAuthCookie などのメソッドを使用して最初に Cookie を設定した後に、フォーム認証 Cookie への参照を取得できます。次に、Response.Cookies[FormsAuthentication.FormsCookieName] の呼び出しによって Cookie への参照を取得できます。開発者は、取得した HttpCookie で Expires プロパティに別の値を設定できます。

存在しないロールを削除しようとした場合、プロバイダの DeleteRole メソッドは、"要素が見つかりません。" という例外を誤ってスローします。この場合、プロバイダは例外ではなく false を返す必要があります。また、既存のユーザーが属しているロールを削除しようとした場合には、プロバイダは例外をスローする代わりに false を返します。

この問題を解決するには

1. プロバイダの DeleteRole メソッドに対する呼び出しをすべて try-catch ブロック内にラップします。こうしておけば、1 つ以上のメンバを含んだロールを削除しようとしたとき例外がスローされるようにする修正が今後行われても、既存のコードには影響がありません。
2. ロールの削除を試みる前に、ロールが存在するかどうかを確認します。

ASP.NET プロファイル機能の既定のプロパティ シリアル化機構は Xml シリアル化です。ASP.NET プロセス ID が ASPNET (IIS 5.0 および IIS 5.1 の場合) または NETWORK SERVICE (IIS 6 の場合) 以外の ID である場合、"InvalidOperationException: 一時クラスを生成できませんでした。" という例外によって、Xml シリアル化プロセスは失敗します。アプリケーションの偽装を使用した場合にも、同じ問題が発生します。これらの例外が発生するのは、XmlSerializer が一時クラス ファイルを %windir%\temp ディレクトリに書き込むためです。既定では、このディレクトリは、既定の ASP.NET アカウントにだけ "フォルダの一覧/データの読み取り" アクセス許可を付与します。既定の ASP.NET アカウント以外のアカウントも、このディレクトリに一時ファイルを書き込むことはできますが、その後に XmlSerializer が使用する一時クラスを検索するために必要な特権はありません。

この問題を解決するには

セキュリティ保護が必要な環境の場合、開発者は別のシリアル化機構 (バイナリ シリアル化または文字列シリアル化) を使用する必要があります。アプリケーション間で一時クラス ファイルを誤って共有する可能性の低いアプリケーションの場合は、ワーカー プロセス ID またはアプリケーションの偽装 ID に %windir%\temp ディレクトリに対する "フォルダの一覧/データの読み取り" 特権を付与できます。

SQL Server Express は、ASP.NET の SQL Server ベースのセッション状態を使用する開発環境でのみ使用してください。これは、SQL Server Express では SQL Server エージェント サービスがインストールされないためです。したがって、セッション状態のクリーンアップ ジョブが実行されることはないため、セッション状態データはデータベースに蓄積されることになります。有効期限の切れたセッションを手動でクリーンアップするには、SQL Server Express に接続し、"EXECUTE DeleteExpiredSessions" コマンドを実行します。

この問題を解決するには

実行用アプリケーションには、SQL Server 2005 の標準バージョンのいずれかを使用します。

承認マネージャでは、"/" 文字が含まれるアプリケーション名は許可されません。構成の applicationName が設定されていない場合、AuthorizationStoreRoleProvider は、他の ASP.NET プロバイダで使用されているロジックにしたがって applicationName の既定値を決定します。ASP.NET 内での実行時には、この値が "/" 文字で始まる値になります。

この問題を解決するには

AuthorizationStoreRoleProvider を ASP.NET アプリケーション内で使用するときは、必ず構成で applicationName 属性を設定します。

Visual Studio 2005 では、Windows 98 または Windows ME で、Web サービスを使用するアプリケーションをデバッグするとアプリケーションがハングします。

この問題を解決するには

デバッガ コンポーネントの csm.dll を無効にし、ブレークポイントを使用して Web サービスを停止します。

csm.dll を無効にするには、以下の手順を実行します。

1) Windows の [スタート] メニューの [ファイル名を指定して実行] をクリックします。
2) [ファイル名を指定して実行] ダイアログ ボックスで「regedit.exe」と入力します。
3) HKEY_CLASSES_ROOT\CLSID\{12A5B9F0-7A1C-4FCB-8163-160A30F519B5} に移動します。
4) InprocServer32\(default) の値が "<ドライブ>:\Program Files\Common Files\Microsoft Shared\VS7Debug\csm.dll" であることをチェックし、正しいレジストリ キーに移動したことを確認します。
5) レジストリ キー (HKEY_CLASSES_ROOT\CLSID\{12A5B9F0-7A1C-4FCB-8163-160A30F519B5}) を削除します。

C# コード スニペットは、.snippet ファイルに XML で定義されます。スキーマで可能なタグの 1 つとして、<Shortcut></Shortcut> タグがあります。ショートカットを使用すると、スニペットをすばやく挿入できます。これを実行するには、ショートカット文字列を入力し、Tab キーを押す必要があります。

ショートカット文字列には多くの Unicode 文字を使用できますが、コンプレックス スクリプトの言語で使用される分音文字は、有効なショートカット文字として認識されません。つまり、コンプレックス スクリプトの言語で表記した文字列は、ショートカットとして使用できない場合があるということです。ショートカットに分音文字が含まれている場合、ショートカット文字列を入力し、Tab キーを押すと、タブ文字は挿入されますが、スニペット コードは挿入されません。
メモ : スニペットのショートカットは IntelliSense でも表示されます。

この問題を解決するには

1. 分音文字が含まれていない Unicode ショートカット名を選択します。
2. ショートカットを使用する代わりに、Snippet Picker の UI を使用してスニペットを挿入します。

以前のバージョンの .NET Framework では、System.Net の DNS は、長時間のネイティブ タイムアウトを回避するために、DNS 型にタイムアウト ロジックを追加していました。正確な DNS タイムアウトがないと、他の Web 要求の正確なタイムアウトを設定できません。ただし、このタイムアウトを実装するために、DNS 解決は別のスレッドにオフロードされます。スレッド プールのレベルが低い場合、DNS 解決はタイムアウトするまで使用可能なスレッドを待機するため、例外がスローされる場合があります。この例外を防ぐために、DNS タイムアウト ロジックが削除されました。

この問題を解決するには

既知の解決策はありません。

SQL Server 2005 でのクエリ通知の動作が変更されたため、開発者は SqlCacheDependency を使用する前に、少なくとも 1 回は SqlDependency の Start メソッドを呼び出す必要があります。Start を呼び出すのに適した場所としては、Web アプリケーションの global.asax にある Application_Start メソッド内が挙げられます。

void Application_Start(object sender, EventArgs e)
{
System.Data.SqlClient.SqlDependency.Start("接続文字列");
}

接続文字列は、SqlCacheDependency で使用するためのコマンドの実行時に使用するものと同じであることが必要です。

以前のバージョンの .NET Framework では、WebClient.UploadValues() の呼び出しによって、アップロードされたコンテンツに CRLF が追加されたため、サーバー アプリケーション エラーになりました。HTML 4.01 仕様に記述されているように、CRLF 文字は application/x-www-form-urlencoded コンテンツ タイプのエンコーディング方式に違反します。CRLF が追加されることはなくなりました。

この問題を解決するには

WebClient.UploadData() を使用して CRLF を追加し、アプリケーションを再コンパイルするか、CRLF 文字を要求しないようサーバー アプリケーションを修正します。

UriBuilder 型を使用すると、Uri インスタンスの内容を少しずつ設定できます。以前のバージョンの .NET Framework では、Query プロパティと Fragment プロパティの両方を設定することはできませんでした。Version 2.0 では、このエラーが修正され、Query プロパティまたは Fragment プロパティに値を設定することによって他のフィールドが不用意に消去されることはなくなりました。以前の動作に合わせてアプリケーションのロジックが作成されている場合は、誤った動作を防ぐために修正が必要になる可能性があります。

この問題を解決するには

既知の解決策はありません。

アプリケーション構成ファイルの System.Net 要素内に存在する設定を適用するために必要なアクセス許可が、以前のバージョンの .NET Framework から変更されています。構成ファイルの値を適用するために必要なアクセス許可は、コード内の設定の変更時に、関連付けられたプロパティで必要とされるアクセス許可と同じになりました。

この問題を解決するには

既知の解決策はありません。

アプリケーションがサーバーに対して FTP 要求を送信した後に、SSL を有効にした状態で同じサーバーに対して同じパスを使用して別の FTP 要求を送信した場合、2 番目の要求は失敗します。この場合、ファイルが見つからないという例外がスローされます。ただし、2 番目の要求が同じパスに対してでなければ、その要求は成功します。

この新しい要求によって、部分信頼で実行されているアプリケーションがネットワーク プロキシ アドレスを見つけることはできなくなります。ServicePoint.Address API を使用する部分的に信頼されたアプリケーションは、アドレスがプロキシ サーバーを指している場合に SecurityException を受け取る場合があります。

この問題を解決するには

HttpWebRequest.Address を使用します。

1. IA64 WOW64 対応の FrontPage Server Extensions

.NET Framework 1.1 を実行しているリモートの IA64 コンピュータ上で、.NET Framework 1.1 を使用して Web サイトを作成する場合に、FrontPage はサポートされません。一部の基本機能は、ファイル共有機構によって動作します。

2. J# は、ネイティブ 64 ビットでの実行をサポートしていません。J# コードは、64 ビット プラットフォーム上の WOW64 でのみ実行できます。

3. SQL Server Express は、.NET Framework 2.0 の 64 ビット版ではサポートされていません。

4. IA64 WOW64 の .NET Framework で実行している負荷の高い ASP.NET アプリケーションについては、パフォーマンスまたはスケーラビリティの保証はありません。

5. データ ブレークポイントは、IA64 の WOW64 上で実行している Visual Studio 2005 では機能しません。

6. Visual Studio 2005 では、エディット コンティニュ デバッガ機能はネイティブ 64 ビット環境では動作しません。ただし、64 ビット WOW 環境では動作します。

7. Visual Studio 2005 での VC ATL の例外は次のとおりです。    

- ビルド システムは、64 ビットを対象とする dll を WOW64 に登録しません。

- 64 ビット コンピュータ上の既定の ATL サーバー プロジェクトのデバッグ時に、"%1 は有効な Win32 アプリケーションではありません。" というエラー メッセージが表示されます。

- デバッグする実行可能ファイルと URL は、64 ビット構成の ATL サーバー プロジェクト用に事前設定されていません。

- 64 ビット ATL サーバー プロジェクトのデバッグ時に、ユーザーが指定した .srf ファイルで Internet Explorer が起動しません。

- ATL Server の 64 ビット構成に対応するデバッガの既定の種類は、Web サービス デバッガではなく、ローカル Windows デバッガです。

- デバッグ プロパティは、プロジェクト内の新しい構成には反映されません。たとえば、x86 の ATL サーバー プロジェクトで開始してからこのプロジェクトの 64 ビット構成を作成した場合、デバッグ対象を Internet Explorer に変更しないとデバッグは機能しなくなります。


8. ネイティブ 64 ビット環境での相互運用機能デバッグ (マネージとアンマネージの混合モードのデバッグ) はサポートされていません。ただし、64 ビット WOW 環境では動作します。

9. 一部の MDA (Re-entrancy、LoaderLock、PInvokeStackImbalance など) は、64 ビットではサポートされていません。

10. MMX 組み込み命令は、IA64 および x64 の C++ コンパイラではサポートされていません。

11. インライン アセンブリは、IA64 および x64 の C++ コンパイラではサポートされていません。

12. 高水準言語のほとんどの構築要素は、x64 MASM ではサポートされていません。
MASM は IA64 をサポートしていませんが、マイクロソフトではインテルのアセンブラ (ias.exe) を出荷しています。

13. Visual Studio 2005 では、VC++ コンパイラ スイッチである /ARCH:SSE は、x64 および IA64 の VC++ コンパイラではサポートされていません。

14. System.Diagnostics.Process.MainModule API および System.Diagnostics.Process.Modules API は、64 ビット子プロセスの WOW64 で実行すると失敗します。

15. 同じ GUID と CLSID を持つ 32 ビットと 64 ビットの COM+ サービス コンポーネントを同時に登録することはできません。

16. 64 ビット版 SDK には、64 ビット ネイティブ DBGCLR は含まれていません。DBGCLR は WOW64 のみです。

17. 64 ビット版 SDK には、64 ビット ネイティブ DEXPLORE.EXE は含まれていません。DEXPLORE.EXE は WOW64 のみです。

18. x64 および IA64 対応のブートストラップ マニフェスト パッケージはありません。

ClickOnce やその他のアプリケーション用の 64 ビット ブートストラップはありません。.NET Framework がインストールされていない 64 ビット コンピュータで、ClickOnce アプリケーションをインストールしようとすると、"64 ビットのオペレーティング システムでは、このバージョンの .NET Framework 2.0 がサポートされません。アプリケーションの開発元に連絡してください。" というメッセージが表示され、インストールできません。

このエラーは、32 ビット版としてのみ作成されたアプリケーションを WOW64 で実行した場合にも発生します。

19. IA64 上には Visual Studio 2005 はインストールされません。

Visual Studio 2005 は、IA64 上にはインストールされません (IA64 のデザイン時のサポートはありません)。Visual C++ には、ネイティブ IA64 のコマンド ライン ツール インストーラがあります。

20. VC++ を使用して IA64 を対象とする 64 ビット ネイティブ アプリケーションの開発を行なう場合は、Visual Studio Team System をお使いいただくか、「Visual Studio 64-bit Hosted Visual C++ Tools 2005」 をお使いください。また、マネージ アプリケーションの開発を行なう場合は、/platform コンパイラ オプションに、対象とするプラットフォームに対応する引数を設定することで、x86、x64、IA64 のいずれか、またはそれら全てのプラットフォーム上で動作させることが可能です。


21. blittable 型を持つ P/Invoke シグネチャは、64 ビットでは扱いが異なります。これは、64 ビットでは P/Invoke の実装が異なるため、32 ビットで誤って動作した不正な P/Invoke シグネチャが 64 ビットで動作しない場合があるためです。

22. Visual Studio 2005 Tools for Office は、64 ビットではサポートされていません。
    

場合によっては、ビルド エラーが含まれていない C# Web サイトでリファクタリング コマンドを実行したときに、プロジェクトまたはその依存関係のいずれかが現在ビルドされておらず、参照を更新できない可能性があることを示す警告が表示されることがあります。
このダイアログは、[続行] または [プレビュー] をクリックすることによって安全に無視できます。リファクタリングは正常に実行され、すべての参照が更新されます。

この警告が表示される一般的なプロジェクト構成の例を次に示します。
- Web ディレクトリに global.asax ファイルが格納され、App_Code ディレクトリに global.asax.cs ファイルが格納された、以前のバージョンの Visual Studio から移行した Web プロジェクト。
- Web ページが Web ユーザー コントロールを参照し、Web ユーザー コントロールが App_Code ディレクトリ内で宣言された型を参照している Web プロジェクト。

この問題を解決するには

既知の解決策はありません。ただし、この警告は安全に無視できます。

.NET Framework 2.0 以前では、System.Net の拡張性のあるプラグ可能なプロトコル フレームワークをアプリケーションで使用することにより、FTP 要求を処理するコンポーネントを登録できました。さまざまな Web 要求を処理するためのコンポーネントは、コンポーネントを特定の URI プレフィックスに関連付けることによって登録されます。このプレフィックスと一致する Web 要求は、プレフィックスに関連付けられたコンポーネントによって処理されます。.NET Framework 2.0 では、System.Net は、既定で "ftp:" プレフィックスに対して登録される FtpWebRequest コンポーネントをサポートするようになりました。このリリース以前にこのプレフィックスに登録しているアプリケーションは、プレフィックス (FTP) が既に取得されているため、破損する可能性があります。

この問題を解決するには

独自の FTP コンポーネントを登録する前に、次のようにアプリケーション構成ファイルを更新して、既定の FTP プロトコル コンポーネントを削除します。
<system.net>
<webRequestModules>
<remove prefix = "ftp:" />
</webRequestModules>
</system.net>

.NET Framework 1.1 では、machine.config ファイルに空の System.Net 要素を指定すると、GlobalProxySelection.Select は、使用できるプロキシが存在しないことを示す空の Web プロキシ インスタンスを返します。.NET Framework 2.0 では、この場合にシステム プロキシ設定 (Internet Explorer で指定するものと同じ設定) が既定で使用されるようになっています。

この問題を解決するには

次のように、machine.config ファイルを変更して既定のプロキシを無効にします。
<system.net>
<defaultProxy enabled="false" />
</system.net>

以前のバージョンの .NET Framework では、IPv6 アドレスを使用して Uri インスタンスを作成すると、ホスト アドレスと共にスコープ ID が必ず含まれます。スコープ ID は、ローカル ネットワーク アダプタのインデックスを参照するため、リモート ホストにとっては意味がありません。また、スコープ ID では構文に '%' 文字を使用するため、Uri エスケープ形式の '%hh' と衝突します。ホストにスコープ ID が含まれていると、他の URI パーサーやリゾルバと相互運用するための System.Uri の機能が損なわれます。Version 2.0 の System.Uri では、Uri インスタンスに IPv6 ホストと共にスコープ ID が含まれることはなくなりました。また、System.Uri には、DnsSafeHost という新しいプロパティも追加されています。このプロパティは、IPv6 ホスト アドレスと共にスコープ ID を返します。

この問題を解決するには

IPv6 ホスト アドレスと共にスコープ ID を返す Uri.DnsSafeHost を使用します。

クラスタに DistributedTransactionManagerName を設定することにより、構成内でクラスタをリモート プロキシとして指定した場合、クラスタのフェールオーバー時に TransactionException がスローされる場合があります。

この問題を解決するには

クラスタをリモート プロキシとして指定するには、コンポーネント サービス MMC を使用して、クラスタをリモート MSDTC として使用するよう MSDTC を構成します。

場合によっては、エディタでさまざなアクションを実行しているときに、"Microsoft Visual C# 2005 IntelliSense でエラーが発生しました。ご不便をおかけして申し訳ありません。" というメッセージが表示されることがあります。ソース データの取得時にエラーが発生したことが原因の場合もあります。

このメッセージが表示される原因となる可能性のあるアクションの例を次に示します。
- 外部エイリアスの名前を変更した場合。
- 'runat="server"' 属性が設定されていない Web プロジェクトで "すべての参照の検索" を実行した場合。

これは致命的な状況ではありません。レポート送信ボタンをクリックすることにより、ユーザーは必要な作業を安全に続行でき、データが失われることもありません。

この問題を解決するには

C# 言語サービスの致命的ではないエラー メッセージの表示をすべて無効にするには、2 つの方法があります。これを実行するには、次のレジストリ パスのレジストリを変更します。

[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0\CSharp\Options\Editor]

(1) "Watson_ReportExceptions"=dword:00000001
指定した値を使用してこのレジストリ キーを追加すると、エラー報告機能が完全に無効になります。

メモ : このレジストリ キーを使用して C# 言語サービスの致命的ではないすべてのエラー メッセージを無効にした場合、このエラーに関連しないシナリオのフィードバックを収集できなくなる可能性があります。

(2) "Watson_DeferSendingUntilLater"=dword:00000000
指定した値を使用してこのレジストリ キーを追加すると、メッセージの表示は無効になりますが、マイクロソフトへのフィードバックの送信は引き続き行うことができます。情報を収集して送信するときに、ごく短時間ですが IDE が応答しなくなります。

トランザクションの上位変換時に、そのトランザクションの DistributedIdentifier を取得しようとすると、NullReferenceException がスローされる場合があります。

この問題を解決するには

この問題を回避するには、2 つの方法があります。

トランザクションへのアクセスが同期されていることを確認します。

または

DistributedIdentifier プロパティをチェックする前に、トランザクションの上位変換が完了していることを確認します。

Visual Studio 2005 で Web 参照を追加すると、サービスの URL は構成ファイルの AppSettings セクションから自動的に取得されます。Web サービスがさまざまな URL で複数のエンドポイントを持つ場合、複数のプロキシ型が生成されますが、これらはすべて構成ファイルから取得した同じ URL 値を使用します。

この問題を解決するには

次の 2 つの方法が可能です。
1. WSDL ドキュメントを編集し、各サービスを個別のドキュメントに分割します。

または
2. 構成ファイルを編集して Web サービスごとにキーを追加し、System.Configuration.ConfigurationSettings.AppSettings を使用してコード内の値を読み取ります。これらの値を使用してプロキシ インスタンスの URL プロパティを設定します。

ASP.NET Web サービスの nullable="true" 属性が含まれたスキーマをインポートすると、生成されるプロキシに Nullable<T> 型が含まれるため、以前の属性は無視されます。この変更により、デザイン時または実行時にアプリケーションが破損する可能性があります。

この問題を解決するには

可能な回避策は、プロキシ型を再生成しないようにすること、新しい Nullable<T> パターンを使用してコードを再コンパイルすること、または nullable="true" 属性を使用しないようにスキーマを変更することです。

Web サービス プロキシ インスタンスで Proxy プロパティに null を設定すると、要求はすべての Web プロキシ サーバー設定を迂回し、サーバーに直接送信するよう強制されます。ただし、この機能は現在動作していません。null 値は無視され、代わりに構成済みの Web プロキシ サーバー設定が使用されます。

この問題を解決するには

次のように、プロキシ型を派生させ、GetWebRequest メソッドをオーバーライドすることにより、基になる WebRequest の Proxy プロパティを直接設定できます。

protected override WebRequest GetWebRequest(Uri uri)
{
WebRequest req = base.GetWebRequest(uri);
req.Proxy = this.proxy;
return req;
}

(.NET Remoting またはランタイム シリアル化を使用して) バージョンの異なる .NET Framework で実行しているアプリケーション間でデータを交換するときに、例外が発生する場合があります。これらの例外は、特定の型に Framework の異なるバージョン間での互換性がないこと、つまり、Framework の異なるバージョン間でその型を送信できないことを示します。

.NET Framework 2.0 には、この問題を解消するための Version Tolerant Serialization と呼ばれるテクノロジが含まれています。ただし、以前のバージョンの Framework では、やはりこの問題が発生します。そのため、一部の Version Tolerant Serialization 機能を .NET Framework 1.1 に追加する更新プログラムを提供する予定です。この更新プログラムには Service Pack 1 が必要となります。更新プログラムをインストールすると、更新プログラムを適用した Framework で実行しているアプリケーションは、このバージョン管理の問題に遭遇することなく、.NET Framework 2.0 で実行しているアプリケーションとやりとりできるようになります。.NET Framework 1.0 に対しては、このような更新プログラムを提供する予定はありません。

直接または .NET Remoting を通じてバイナリ シリアル化を使用する際に、バージョン管理に対処するのは Version Tolerant Serialization だけであるという点に注意してください。Framework のさまざまなバージョン間で SOAP シリアル化を使用する場合 (SoapFormatter クラスから直接使用するか、.NET Remoting を通じて使用します) には、前述のバージョン管理の問題が発生する可能性があります。

この問題を解決するには

この更新プログラムを入手するには、サポート技術情報の文書 (http://support.microsoft.com/?kbid=907262) を参照してください。

構成で System.Transactions のトレースに特定のトレース リスナを指定することは部分信頼でサポートされていないため、これを指定すると例外がスローされます。

この問題を解決するには

既定のトレース リスナは、部分信頼でサポートされています。そのため、構成でリスナが指定されていない場合、トレースは既定のリスナによってキャッチされ、debug.outputstring に出力されます。これらのトレースは、DBMon.exe を使用することで部分信頼で表示できます。

.NET Framework 2.0 では、XML に対する日付と時刻の書き込みと読み取りの方法が変更されています。この変更の影響を受けるのは、主に次のシナリオです。
- タイム ゾーンが指定されていない時刻、または UTC タイム ゾーンの時刻を使用する場合
- タイム ゾーンまたは UTC タイム ゾーンを指定せずに XML に時刻値を書き込むサードパーティ製ソフトウェアとの相互運用性のシナリオ

この変更によって、一部の日付と時刻の計算および比較に誤りが生じる場合があります。これらのケースでは、以前の日付/時刻の動作に戻すことが必要な場合があります。

この問題を解決するには

以前の日付/時刻の動作に戻すには、次の構成変更を適用します。

<system.xml.serialization>
<dateTimeSerialization mode="Local" />
</system.xml.serialization>

SQL Server Express (SSE) と IIS を使用した ASP.NET の SQL Server プロバイダ用 MDF 自動作成プロセスは、IIS が ASP.NET のローカル コンピュータ アカウントまたは NT AUTHORITY\NETWORK SERVICE として実行されている場合にのみ機能します。この自動作成プロセスは、Visual Web Developer Web Server を使用して対話的に開発している場合 (ファイル ベースの Web サイト) にも機能します。ただし、別のローカル コンピュータ アカウントまたはドメイン ユーザー アカウントを使用して、IIS に対して開発作業を行う場合、データベース自動作成プロセスは失敗します。これは、これらのアカウントには Web サーバーで使用できる Windows ユーザー プロファイルがないためです。

この問題を解決するには

この問題の解決策はありません。IIS ベースの Web サイトのための SSE を使用したデータベース自動作成が機能するのは、ASPNET アカウントおよび NETWORK SERVICE アカウントを使用している場合だけです。

SQL Server を使用する ASP.NET プロバイダは、SQL Server 7.0 および SQL Server 2000 で提供されている Unicode サロゲートのサポートのレベルによって制約を受けます。SQL Server 7.0 および 2000 は、情報を損なうことなくサロゲート ペアを格納および取得します。ただし、サロゲートの言語比較は行いません。これらのバージョンの SQL Server を使用している場合、比較演算の実行時および一意性の検証時にサロゲート文字は無視されます。たとえば、これは SqlMembershipProvider がサロゲート文字だけが含まれた 2 つのユーザー名を同一と見なすということです。サロゲート文字だけが既存のユーザーとは異なるユーザー名で 2 つ目のユーザーを作成しようとした場合に、この動作は一意性の制約違反の原因となります。

この問題を解決するには

これらのバージョンの SQL Server に関する既知の解決策はありません。

WebRequest から継承した型は、PreAuthenticate プロパティを継承します。このプロパティは、サーバーからのチャレンジを待機せずに、認証情報を要求と共に送信できるようにするために使用します。FileWebRequest は事前認証をサポートしていないため、PreAuthenticate プロパティは常に false を返します。以前のバージョンの .NET Framework では、アプリケーションによって PreAuthenticate プロパティに true が設定された場合、後で値が照会されたときに、このプロパティは true を返していました。今後、このようなことはなくなります。FileWebRequest の PreAuthenticate プロパティは常に false を返します。

この問題を解決するには

FileWebRequest の PreAuthenticate プロパティを使用しないようにします。

.NET Remoting テクノロジでは、バイナリ シリアル化と SOAP シリアル化の両方をサポートしてい�