Windows フォーム デザイナ上にコントロールを生成するために、データベース データ ソースからフィールドを (ドラッグ アンド ドロップではなく) コピーして貼り付けると、データ バインド関連のプロパティが、テーブル内のフィールドではなくテーブルに設定されます。オブジェクトと Web データ ソースはこの問題の影響を受けません。
この問題を解決するには
Windows フォーム デザイナに追加するそれぞれのコントロールのプロパティを編集して、(DataBindings) プロパティを正しいデータ ソースに変更します。
2. Visual C# 2005 Express
2.1 C# コード スニペットのショートカットに分音文字を含めることはできない
C# コード スニペットは、.snippet ファイルに XML で定義されます。スキーマで可能なタグの 1 つとして、<Shortcut></Shortcut> タグがあります。ショートカットを使用すると、スニペットをすばやく挿入できます。これを実行するには、ショートカット文字列を入力し、Tab キーを押す必要があります。
ショートカット文字列には多くの Unicode 文字を使用できますが、コンプレックス スクリプトの言語で使用される分音文字は、有効なショートカット文字として認識されません。つまり、コンプレックス スクリプトの言語で表記した文字列は、ショートカットとして使用できない場合があるということです。ショートカットに分音文字が含まれている場合、ショートカット文字列を入力し、Tab キーを押すと、タブ文字は挿入されますが、スニペット コードは挿入されません。
メモ : スニペットのショートカットは IntelliSense でも表示されます。
この問題を解決するには
1. 分音文字が含まれていない Unicode ショートカット名を選択します。
2. ショートカットを使用する代わりに、Snippet Picker の UI を使用してスニペットを挿入します。
2.2 [必須コンポーネント] ダイアログに表示される Microsoft Visual J# Redistributable 2.0 パッケージの警告
Microsoft Visual J# Redistributable 2.0 のパッケージは、警告アイコンと共に [必須コンポーネント] ダイアログに表示されます。このダイアログは、プロジェクト デザイナの [発行] タブから使用できます。
この問題を解決するには
この警告は安全に無視できます。
2.3 Express を使用して作成した一部のアプリケーションを、x64 Windows 上でデバッグまたは実行できない
既定では、Visual Basic 2005 Express、Visual C# 2005 Express、または Visual J# 2005 Express を使用して作成したアプリケーションは、"AnyCPU" (任意の CPU) に読み込まれるように設定されています。これらのアプリケーションは、64 ビット CLR が存在する場合はこの CLR に読み込まれますが、存在しない場合は 32 ビット CLR に読み込まれます。ただし、64 ビット CLR で実行されている場合には機能しないタイプのアプリケーションもあります。特に、32 ビット COM コンポーネントまたは DirectX の一部のバージョンへの参照を使用するアプリケーションは、64 ビット上で正しく実行されない場合があります。Express Edition 以外の Visual Studio 製品ではプラットフォーム ターゲットを "AnyCPU" から "x86" に変更できますが、このオプションは Express Edition では使用できません。
この問題を解決するには
1. [ツール] の [オプション] を開きます。
2. [すべての設定を表示] チェック ボックスをオンにします。
3. [プロジェクトおよびソリューション] の [ビルド構成の詳細を表示] チェック ボックスをオンにします。
4. [ビルド] の [構成マネージャ] を開きます。
5. x86 を対象とするプロジェクトの [プラットフォーム] 列下でコンボ ボックスを選択します。
6. [<新規作成...>] を選択します。
7. [新しいプラットフォーム] 下で x86 を選択します。
8. [OK] をクリックし、[閉じる] をクリックします。
9. プラットフォーム構成の [ツール バー] ボックスで、x86 と AnyCPU の両方が表示され、x86 が選択されていることを確認します。
10. これで、ビルド、実行、およびデバッグによって x86 専用のバイナリがビルドされるようになります。AnyCPU 構成に戻して、この設定を変更することもできます。
2.4 IDE でさまざまなアクションを実行しているときに、"Microsoft Visual C# 2005 IntelliSense でエラーが発生しました。" というメッセージが表示される場合がある
場合によっては、エディタでさまざまなアクションを実行しているときに、"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
指定した値を使用してこのレジストリ キーを追加すると、エラー メッセージの表示は無効になりますが、Microsoft へのフィードバックの送信は引き続き行うことができます。情報を収集して送信するときに、ごく短時間ですが IDE が応答しなくなります。
2.5 [設定としてユーザー定義された型] を使用すると、設定デザイナで予期しない動作の原因となる場合がある
[設定としてユーザー定義された型] を使用すると、UDT が含まれるアセンブリを使用するプロジェクトを開いているときに、そのアセンブリを更新した場合、問題が発生することがあります。このシナリオが必要な場合は、UDT アセンブリでインクリメンタル バージョン セマンティクスを使用することで、この問題を回避できます。
この問題を解決するには
設定として使用するユーザー定義型がクラス ライブラリに存在する場合、ライブラリをインクリメンタル方式でバージョン化して問題を軽減します。ユーザー定義型が EXE 内に存在する場合は、IDE を閉じ、再起動して UDT への変更を有効にする必要があります。
2.6 C# Express をアンインストールすると、Visual Studio コンテンツ インストーラの実行に失敗する
C# Express をインストールし、次に Visual Studio の他の Edition をインストールした後、C# Express をアンインストールすると、Visual Studio コンテンツ インストーラの起動に失敗する場合があります。
この問題を解決するには
Visual Studio で修復機能を実行します。
3. Visual Basic 2005 Express
3.1 ユーザー コントロール プロジェクト内の "My" にフォーム プロパティがない
My.Forms は、ユーザー コントロール プロジェクトでは使用できません。
3.2 リモート デバッグ時に Sleep 呼び出しで中断した場合、オブジェクトのメソッドを呼び出せない
リモート コンピュータで次のコードを実行しているとき、実行中のコードにリモート デバッグで接続し、Sleep() 呼び出しの内部で実行を中断したとすると、変数 c のメンバを評価することはできません。
c = New c1 'c1 は有効なクラスであることが前提
While True
Threading.Thread.Sleep(1000)
End While
この問題を解決するには
Sleep() からステップ アウトすると、通常どおりオブジェクトを評価できるようになります。
3.3 ActiveX EXE オブジェクトのバリアント プロパティに構造体を渡すことはできない
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 を手動で呼び出します。
3.4 循環制約が指定された型パラメータで New を使用すると、Visual Basic コンパイラがハングし、メモリの割り当てが増加する
コンソール アプリケーションに以下のコードを貼り付けると、アプリケーションがハングします。
Class C1(Of U As U) 'この循環制約によって後で問題が生じる
End Class
Partial Class C1(Of U)
Dim x As New U '問題 ? これが原因で無限ループが発生し、メモリを使用できなくなるまでメモリ使用量が増え続ける
End Class
この問題を解決するには
循環制約を削除します。
3.5 ClickOnce を使用してアプリケーションを起動した場合、StartupNextInstanceEvent ハンドラに対するパラメータにコマンド ライン引数が含まれない
ClickOnce を使用してアプリケーションを起動した場合、StartupNextInstanceEvent ハンドラに対するパラメータにアプリケーションの 2 つ目のインスタンスのコマンド ライン引数は含まれません。My.Application.Deployment.ActivationUri プロパティを使用して、コマンド ライン引数を取得する必要があります。
この問題を解決するには
次のように、ASP ランタイム クラスを使用してコマンド ライン引数を取得します。
Imports System.Web
Dim commandLineArgs as NameValueCollection = _
HttpUtility.ParseQuery(My.Application.Deployment.ActivationUri)
3.6 Visual Basic コンパイラは InternalsVisibleTo 属性をサポートしていない
<Assembly : InternalsVisibleTo("Foo.Dll, PublicKeyToken=a29c01bbd4e39ac5")>
この属性は、Friend 型を他のアセンブリに公開します。この属性は、Visual Basic コンパイラではサポートされていません。
プライベート型をテストするためにこの属性に依存する一部の単体テスト テクノロジは、期待どおりに動作しません。
この問題を解決するには
既知の解決策はありません。
3.7 [必須コンポーネント] ダイアログに表示される Microsoft Visual J# Redistributable 2.0 パッケージの警告
Microsoft Visual J# Redistributable 2.0 のパッケージは、警告アイコンと共に [必須コンポーネント] ダイアログに表示されます。このダイアログは、プロジェクト デザイナの [発行] タブから使用できます。
この問題を解決するには
既知の解決策はありません。
3.8 ユーザーにファイル I/O アクセス許可がない場合、My.Application.Log.WriteEntry が例外をスローすることがある
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) すべてのログ呼び出し (少なくとも、最初に実行すると思われる呼び出し) を試行またはキャッチします。
3.9 [設定としてユーザー定義された型] を使用すると、設定デザイナで予期しない動作の原因となる場合がある
[設定としてユーザー定義された型] を使用すると、UDT が含まれるアセンブリを使用するプロジェクトを開いているときに、そのアセンブリを更新した場合、問題が発生することがあります。このシナリオが必要な場合は、UDT アセンブリでインクリメンタル バージョン セマンティクスを使用することで、この問題を回避できます。
この問題を解決するには
設定として使用するユーザー定義型がクラス ライブラリに存在する場合、ライブラリをインクリメンタル方式でバージョン化して問題を軽減します。ユーザー定義型が EXE 内に存在する場合は、IDE を閉じ、再起動して UDT への変更を有効にする必要があります。
3.10 Long (VT_I8) の相互運用は Windows XP でしかサポートされていない
Long (VT_I8) を渡す Windows 2000 または Windows 9x での遅延バインド呼び出しは失敗します。OLE オートメーション経由の VT_I8 でサポートされているプラットフォームは Windows XP だけです。
この問題を解決するには
Long 型ではなく整数を使用します。
4. Visual J# 2005 Express
4.1 [設定としてユーザー定義された型] を使用すると、設定デザイナで予期しない動作の原因となる場合がある
[設定としてユーザー定義された型] を使用すると、UDT が含まれるアセンブリを使用するプロジェクトを開いているときに、そのアセンブリを更新した場合、問題が発生することがあります。このシナリオが必要な場合は、UDT アセンブリでインクリメンタル バージョン セマンティクスを使用することで、この問題を回避できます。
この問題を解決するには
設定として使用するユーザー定義型がクラス ライブラリに存在する場合、ライブラリをインクリメンタル方式でバージョン化して問題を軽減します。ユーザー定義型が EXE に存在する場合は、IDE を閉じ、再起動して UDT への変更を有効にする必要があります。
5. Visual C++ 2005 Express
5.1 [設定としてユーザー定義された型] を使用すると、設定デザイナで予期しない動作の原因となる場合がある
[設定としてユーザー定義された型] を使用すると、UDT が含まれるアセンブリを使用するプロジェクトを開いているときに、そのアセンブリを更新した場合、問題が発生することがあります。このシナリオが必要な場合は、UDT アセンブリでインクリメンタル バージョン セマンティクスを使用することで、この問題を回避できます。
この問題を解決するには
設定として使用するユーザー定義型がクラス ライブラリに存在する場合、ライブラリをインクリメンタル方式でバージョン化して問題を軽減します。ユーザー定義型が EXE 内に存在する場合は、IDE を閉じ、再起動して UDT への変更を有効にする必要があります。
6. .NET Framework
6.1 AuthorizationStoreRoleProvider : 承認マネージャから誤ったエラーまたは不明瞭なエラーが返される
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 つとして考えられる場合は、上記の情報を基にアプリケーションの構成を変更または修正します。
6.2 共有ホスト コンピュータでは、SQL Server 2005 Express のユーザー インスタンスを無効にする必要がある
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 Express をインストールする場合は、高度なセットアップ オプションを使用することで、ユーザー インスタンス機能のサポートを明示的に無効にできます。
次のように、既存の SQL Server Express インストールのユーザー インスタンス機能を手動で無効にすることもできます。
1. ローカル ボックス管理者としてログインし、cmd.exe を実行してコマンド ウィンドウを開きます。
2. PATH 環境変数に示されたディレクトリから osql.exe を使用できない場合は、ディレクトリを osql.exe を格納する SQL Server 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
6.3 フォーム認証の永続 Cookie の動作が、セッション ベースの Cookie と同じタイムアウト設定を使用するように変更されている
以前のバージョンの 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 プロパティに別の値を設定できます。
6.4 AuthorizationStoreRoleProvider の DeleteRole メソッドの動作が適切でない
存在しないロールを削除しようとした場合、プロバイダの DeleteRole メソッドは、"要素が見つかりません。" という例外を誤ってスローします。この場合、プロバイダは例外ではなく false を返す必要があります。また、既存のユーザーが属しているロールを削除しようとした場合には、プロバイダは例外をスローする代わりに false を返します。
この問題を解決するには
1. プロバイダの DeleteRole メソッドに対する呼び出しをすべて try-catch ブロック内にラップします。こうしておけば、1 つ以上のメンバを含んだロールを削除しようとしたとき例外がスローされるようにする修正が今後行われても、既存のコードには影響がありません。
2. ロールの削除を試みる前に、ロールが存在するかどうかを確認します。
6.5 Xml シリアル化と既定のアプリケーション ID 以外の ID を使用すると、ASP.NET プロファイル機能が失敗する可能性がある
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 ディレクトリに対する "フォルダの一覧/データの読み取り" 特権を付与できます。
6.6 SQL Server Express 使用時の ASP.NET のセッション状態の制限
SQL Server Express は、ASP.NET の SQL Server ベースのセッション状態を使用する開発環境でのみ使用してください。これは、SQL Server Express では SQL Server エージェント サービスがインストールされないためです。したがって、セッション状態のクリーンアップ ジョブが実行されることはないため、セッション状態データはデータベースに蓄積されることになります。有効期限の切れたセッションを手動でクリーンアップするには、SQL Server Express に接続し、"EXECUTE DeleteExpiredSessions" コマンドを実行します。
この問題を解決するには
実行用アプリケーションには、SQL Server 2005 の標準バージョンのいずれかを使用します。
6.7 AuthorizationStoreRoleProvider : ApplicationName の既定値が承認マネージャでエラーになる
承認マネージャでは、"/" 文字が含まれるアプリケーション名は許可されません。構成の applicationName が設定されていない場合、AuthorizationStoreRoleProvider は、他の ASP.NET プロバイダで使用されているロジックにしたがって applicationName の既定値を決定します。ASP.NET 内での実行時には、この値が "/" 文字で始まる値になります。
この問題を解決するには
AuthorizationStoreRoleProvider を ASP.NET アプリケーション内で使用するときは、必ず構成で applicationName 属性を設定します。
6.8 System.Net では、DNS タイムアウトが DNS 解決を実行するために System.Net によって呼び出されるアンマネージ API のタイムアウトよりも短い場合に DNS 解決をタイムアウトするロジックが削除されている
以前のバージョンの .NET Framework では、System.Net の DNS は、長時間のネイティブ タイムアウトを回避するために、DNS 型にタイムアウト ロジックを追加していました。正確な DNS タイムアウトがないと、他の Web 要求の正確なタイムアウトを設定できません。ただし、このタイムアウトを実装するために、DNS 解決は別のスレッドにオフロードされます。スレッド プールのレベルが低い場合、DNS 解決はタイムアウトするまで使用可能なスレッドを待機するため、例外がスローされる場合があります。この例外を避けるために、DNS タイムアウト ロジックが削除されました。
この問題を解決するには
既知の解決策はありません。
6.9 SqlCacheDependency は、System.Data.SqlClient.SqlDependency.Start の呼び出しによって初期化する必要がある
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 で使用するためのコマンドの実行時に使用するものと同じであることが必要です。
6.10 System.Net は、WebClient.UploadValues() の呼び出し時に CRLF 文字列を追加しないように変更されている
以前のバージョンの .NET Framework では、WebClient.UploadValues() の呼び出しによって、アップロードされたコンテンツに CRLF が追加されたため、サーバー アプリケーション エラーになりました。HTML 4.01 仕様に記述されているように、CRLF 文字は application/x-www-form-urlencoded コンテンツ タイプのエンコーディング方式に違反します。CRLF が追加されることはなくなりました。
この問題を解決するには
WebClient.UploadData() を使用して CRLF を追加し、アプリケーションを再コンパイルするか、CRLF 文字を要求しないようサーバー アプリケーションを修正します。
6.11 UriBuilder が、Fragment プロパティまたは Query プロパティに設定した値が後で消去されることがないよう変更されている
UriBuilder 型を使用すると、Uri インスタンスの内容を少しずつ設定できます。以前のバージョンの .NET Framework では、Query プロパティと Fragment プロパティの両方を設定することはできませんでした。 Version 2.0 では、このエラーが修正され、Query プロパティまたは Fragment プロパティに値を設定することによって他のフィールドが不用意に消去されることはなくなりました。以前の動作に合わせてアプリケーションのロジックが作成されている場合は、誤った動作を防ぐために修正が必要になる可能性があります。
この問題を解決するには
既知の解決策はありません。
6.12 アプリケーション構成ファイルの System.Net 要素内に存在する値を適用する前に必要なアクセス許可が変更されている
アプリケーション構成ファイルの System.Net 要素に存在する設定を適用するために必要なアクセス許可が、以前のバージョンの .NET Framework から変更されました。構成ファイルの値を適用するために必要なアクセス許可は、コード内の設定の変更時に、関連付けられたプロパティで必要とされるアクセス許可と同じになりました。
この問題を解決するには
既知の解決策はありません。
6.13 FTP 要求を送信した後に、同じディレクトリに対して SSL (FTPs) を使用して FTP 要求を送信すると、"ファイルが見つかりません" という例外がスローされる
アプリケーションがサーバーに対して FTP 要求を送信した後に、SSL を有効にした状態で同じサーバーに対して同じパスを使用して別の FTP 要求を送信した場合、2 番目の要求は失敗します。この場合、ファイルが見つからないという例外がスローされます。ただし、2 番目の要求が同じパスに対してでなければ、その要求は成功します。
6.14 WebRequest.ServicePoint.Address は、当該のサービス ポイントがプロキシ サーバーの場合にだけ、制限されていない Web アクセス許可を要求する
この新しい要求によって、部分信頼で実行されているアプリケーションがネットワーク プロキシ アドレスを見つけることはできなくなります。ServicePoint.Address API を使用する部分的に信頼されたアプリケーションは、アドレスがプロキシ サーバーを指している場合に SecurityException を受け取ることがあります。
この問題を解決するには
HttpWebRequest.Address を使用します。
6.15 System.Net で登録できるようになった既定の FtpWebRequest 実装によって、独自の FTP コンポーネントを使用するアプリケーションが破損する場合がある
.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>
6.16 .NET Framework 2.0 で、machine.config ファイルに空の System.Net タグが存在する場合に、GlobalProxySelection.Select の動作が Version 1.1 と異なる
.NET Framework Version 1.1 では、machine.config ファイルに空の System.Net 要素を指定すると、GlobalProxySelection.Select は、使用できるプロキシが存在しないことを示す空の Web プロキシ インスタンスを返します。Version 2.0 では、この場合にシステム プロキシ設定 (Internet Explorer で指定するものと同じ設定) が既定で使用されるようになっています。
この問題を解決するには
次のように、machine.config ファイルを変更して既定のプロキシを無効にします。
<system.net>
<defaultProxy enabled="false" />
</system.net>
6.17 System.Uri でホストと共に IPv6 スコープ ID が含まれていない
以前のバージョンの .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 を使用します。
6.18 System.Transactions の構成を使用して、リモート プロキシとしてクラスタを指定すると、クラスタのフェールオーバー時に TransactionException がスローされる場合がある
クラスタに DistributedTransactionManagerName を設定することにより、構成内でクラスタをリモート プロキシとして指定した場合、クラスタのフェールオーバー時に TransactionException がスローされる場合があります。
この問題を解決するには
クラスタをリモート プロキシとして指定するには、コンポーネント サービス MMC を使用して、クラスタをリモート MSDTC として使用するよう MSDTC を構成します。
6.19 トランザクションの上位変換時に、トランザクションの DistributedIdentifier を取得しようとすると NullReferenceException がスローされる
トランザクションの上位変換時に、そのトランザクションの DistributedIdentifier を取得しようとすると、NullReferenceException がスローされる場合があります。
この問題を解決するには
この問題を回避するには、2 つの方法があります。
トランザクションへのアクセスが同期されていることを確認します。
または
DistributedIdentifier プロパティをチェックする前に、トランザクションの上位変換が完了していることを確認します。
6.20 [Web 参照の追加] を使用して生成されたすべての ASP.NET Web サービス プロキシは、サービスがさまざまな URL で複数のエンドポイントを持つ場合でも、構成ファイルから取得した同じ URL を使用する
Visual Studio 2005 で Web 参照を追加すると、サービスの URL は構成ファイルの AppSettings セクションから自動的に取得されます。Web サービスがさまざまな URL で複数のエンドポイントを持つ場合、複数のプロキシ型が生成されますが、これらはすべて構成ファイルから取得した同じ URL 値を使用します。
この問題を解決するには
次の 2 つの方法が可能です。
1. wsdl ドキュメントを編集し、各サービスを個別のドキュメントに分割します。
または
2. 構成ファイルを編集して Web サービスごとにキーを追加し、System.Configuration.ConfigurationSettings.AppSettings を使用してコード内の値を読み取ります。これらの値を使用してプロキシ インスタンスの URL プロパティを設定します。
6.21 生成される ASP.NET Web サービス プロキシでは既定で Nullable<T> がサポートされ、これによりプロキシの再生成時に既存のコードが破損する可能性がある
ASP.NET Web サービスの nullable="true" 属性が含まれたスキーマをインポートすると、生成されるプロキシに Nullable<T> 型が含まれるため、以前の属性は無視されます。この変更により、デザイン時または実行時にアプリケーションが破損する可能性があります。
この問題を解決するには
可能な回避策は、プロキシ型を再生成しないようにすること、新しい Nullable<T> パターンを使用してコードを再コンパイルすること、または nullable="true" 属性を使用しないようにスキーマを変更することです。
6.22 Web サービス プロキシ インスタンスで Proxy プロパティに null を設定しても、要求がサーバーに直接送信されない
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;
}
6.23 .NET Framework の異なるバージョン間で .NET Remoting およびランタイム シリアル化を使用する場合の注意事項
(.NET Remoting またはランタイム シリアル化を使用して) バージョンの異なる .NET Framework で実行しているアプリケーション間でデータを交換するときに、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) を参照してください。
6.24 System.Transactions のトレースに既定以外のトレース リスナを指定すると部分信頼で動作しない
構成で System.Transactions のトレースに特定のトレース リスナを指定することは部分信頼でサポートされていないため、これを指定すると例外がスローされます。
この問題を解決するには
既定のトレース リスナは、部分信頼でサポートされています。そのため、構成でリスナが指定されていない場合、トレースは既定のリスナによってキャッチされ、debug.outputstring に出力されます。これらのトレースは、DBMon.exe を使用することで部分信頼で表示できます。
6.25 .NET Framework 2.0 に移行後、Web サービスまたは XML シリアル化のシナリオでの日付と時刻の計算が間違っている場合がある
.NET Framework 2.0 では、XML に対する日付と時刻の書き込みと読み取りの方法が変更されています。この変更の影響を受けるのは、主に次のシナリオです。
- タイム ゾーンが指定されていない時刻、または UTC タイム ゾーンの時刻を使用する場合。
- タイム ゾーンまたは UTC タイム ゾーンを指定せずに XML に時刻値を書き込むサードパーティ製ソフトウェアとの相互運用性のシナリオ。
この変更によって、一部の日付と時刻の計算および比較に誤りが生じる場合があります。これらのケースでは、以前の日付/時刻の動作に戻すことが必要な場合があります。
この問題を解決するには
以前の日付/時刻の動作に戻すには、次の構成変更を適用します。
<system.xml.serialization>
<dateTimeSerialization mode="Local" />
</system.xml.serialization>
6.26 SQL Server 2005 Express と IIS を使用した ASP.NET データベース自動作成に対応する Windows ユーザー プロファイル
SQL Server 2005 Express および IIS を使用した ASP.NET の SQL Server プロバイダ用の MDF 自動作成プロセスは、IIS がローカルな ASPNET コンピュータ アカウントまたは NT AUTHORITY\NETWORK SERVICE として実行されている場合にのみ機能します。この自動作成プロセスは、Visual Web Developer Web Server (つまり、ファイル ベースの Web) を使用して対話的に開発している場合にも機能します。ただし、別のローカル コンピュータ アカウントまたはドメイン ユーザー アカウントを使用して、IIS に対して開発作業を行う場合、データベース自動作成プロセスは失敗します。これは、これらのアカウントには Web サーバーで使用できる Windows ユーザー プロファイルがないためです。
この問題を解決するには
現在のところ、この問題の回避策はありません。IIS ベースの Web サイトのための SQL Server Express を使用したデータベース自動作成が機能するのは、ASPNET アカウントおよび NETWORK SERVICE アカウントを使用している場合だけです。
6.27 SQL Server 7.0 または 2000 を使用する ASP.NET プロバイダにおける Unicode サロゲートの動作
SQL Server を使用する ASP.NET プロバイダは、SQL Server 7.0 および SQL Server 2000 で提供されている Unicode サロゲートのサポートのレベルによって制約を受けます。SQL Server 7.0 および 2000 は、情報を損なうことなくサロゲート ペアを格納および取得します。ただし、サロゲートの言語比較は行いません。これらのバージョンの SQL Server を使用している場合、比較演算の実行時および一意性の検証時にサロゲート文字は無視されます。たとえば、これは SqlMembershipProvider がサロゲート文字だけが含まれた 2 つのユーザー名を同一と見なすということです。サロゲート文字だけが既存のユーザーとは異なるユーザー名で 2 つ目のユーザーを作成しようとした場合に、この動作は一意性の制約違反の原因となります。
この問題を解決するには
既知の解決策はありません。
6.28 FileWebRequest.PreAuthenticate が常に false を返す
WebRequest から継承した型は、PreAuthenticate プロパティを継承します。このプロパティは、サーバーからのチャレンジを待機せずに、認証情報を要求と共に送信できるようにするために使用します。FileWebRequest は事前認証をサポートしていないため、PreAuthenticate プロパティは常に false を返します。以前のバージョンの .NET Framework では、アプリケーションによって PreAuthenticate プロパティに true が設定された場合、後で値が照会されたときに、このプロパティは true を返していました。今後、このようなことはなくなります。FileWebRequest の PreAuthenticate プロパティは常に false を返します。
この問題を解決するには
FileWebRequest の PreAuthenticate プロパティを使用しないようにします。
6.29 .NET Remoting と SOAP シリアル化でのジェネリック型の使用
.NET Remoting テクノロジでは、バイナリ シリアル化と SOAP シリアル化の両方をサポートしています。つまり、リモート処理メッセージは、Microsoft 固有のバイナリ形式または SOAP XML で表すことができます。ただし、ジェネリック型 (.NET Framework 2.0 の新機能) を使用できるのはバイナリ シリアル化だけです。.NET Remoting を通じて行うか、SoapFormatter クラスを使用して直接行うかを問わず、SOAP シリアル化でのジェネリックの使用はサポートされていません。
この問題を解決するには
既知の解決策はありません。
6.30 .NET Remoting またはバイナリ シリアル化でジェネリック型を使用すると、バージョン管理が機能しないことがある
.NET Remoting とバイナリ シリアル化は、疎結合モード (FormatterAssemblyStyle を Simple、includeVersions を False、strictBinding を False に設定して選択) で機能できます。このモードでは、シリアル化されたアセンブリのバージョンが、シリアル化を解除して読み込まれるアセンブリのバージョンと一致する必要はありません。この機能は、簡単にバージョン管理を行えるようにする目的で用意されています。たとえば、.NET Remoting サーバーを更新しても、クライアントは更新する必要がありません。
ただし、このバージョン管理が機能しない場合があります。具体的には、ジェネリック型を使用している場合、ジェネリック パラメータ型のアセンブリのバージョンを変更すると、疎結合モードでもシリアル化の解除に失敗することがあります。たとえば、MyType2 の型パラメータを使用して MyType1 のシリアル化を解除する場合、MyType2 が含まれたアセンブリをシリアル化したときのバージョンと、そのシリアル化を解除するときのバージョンが異なると、シリアル化の解除に失敗することがあります。
この問題を解決するには
この制限を回避するには、バージョン管理が重要な状況では .NET Remoting およびバイナリ シリアル化でのジェネリック型の使用を避けます。それ以外の場合は、.NET Framework アセンブリ バインド リダイレクト機能を使って、存在しないアセンブリのバージョンに対する読み込み要求を、シリアル化の解除を実行するコンピュータ上に実際に存在するバージョンにリダイレクトします。その他の回避策として、AssemblyResolve イベントを使用してアセンブリの読み込みエラーを検出し、その名前の一部のみを使用してアセンブリの読み込みを再試行する方法があります。
7. MSDN Express
現時点では既知の問題はありません。
8. Visual Studio Integrated Development Environment
現時点では既知の問題はありません。
9. Visual Web Developer 2005 Express
9.1 C# Web サイトでのリファクタリング操作の実行時に、実際にはエラーが存在しなくても、ビルド エラーが報告される場合がある
場合によっては、ビルド エラーが含まれていない C# Web サイトでリファクタリング コマンドを実行したときに、プロジェクトまたはその依存関係のいずれかが現在ビルドされておらず、参照を更新できない可能性があることを示す警告が表示されることがあります。
このダイアログは、[続行] または [プレビュー] をクリックすることによって安全に無視できます。リファクタリングは正常に実行され、すべての参照が更新されます。
この警告が表示される一般的なプロジェクト構成の例を次に示します。
- Web ディレクトリに global.asax ファイルが格納され、App_Code ディレクトリに global.asax.cs ファイルが格納された、以前のバージョンの Visual Studio から移行した Web プロジェクト。
- Web ページが Web ユーザー コントロールを参照し、Web ユーザー コントロールが App_Code ディレクトリ内で宣言された型を参照している Web プロジェクト。
この問題を解決するには
既知の解決策はありません。 ただし、この警告は安全に無視できます。
9.2 C# コード スニペットのショートカットに分音文字を含めることはできない
C# コード スニペットは、.snippet ファイルに XML で定義されます。スキーマで可能なタグの 1 つとして、<Shortcut></Shortcut> タグがあります。ショートカットを使用すると、スニペットをすばやく挿入できます。これを実行するには、ショートカット文字列を入力し、Tab キーを押す必要があります。
ショートカット文字列内には多くの Unicode 文字を使用できますが、分音文字は使用できません。つまり、ある種の言語で表記した文字列は、ショートカットとして使用できない場合があるということです。ショートカットに分音文字が含まれている場合、ショートカット文字列を入力し、Tab キーを押すと、タブ文字は挿入されますが、スニペット コードは挿入されません。
この問題を解決するには
1. 分音文字が含まれていない Unicode ショートカット名を選択します。
2. ショートカットを使用する代わりに、Snippet Picker の UI を使用してスニペットを挿入します。
9.3 FTP Web サイトのサーバー エクスプローラでデータ ファイルを展開すると、IDE がクラッシュする可能性がある
FTP Web サイトを開き、データ ファイル (MDB または MDF) を App_Data ディレクトリに追加した後に、[サーバー エクスプローラ] ウィンドウを開き、Data Connections ノードの
データ ファイルへの接続を展開した場合、IDE がクラッシュまたはハングする可能性があり、保存していないデータが失われることがあります。
この問題を解決するには
ファイル システムまたは IIS Web サイトを使用して、ローカル ファイルの場所から Web サイトを開発し、[Web サイトのコピー] コマンドを使用して、FTP パスとの間でファイルを転送します。
9.4 [設定としてユーザー定義された型] を使用すると、設定デザイナで予期しない動作の原因となる場合がある
[設定としてユーザー定義された型] を使用すると、UDT が含まれるアセンブリを使用するプロジェクトを開いているときに、そのアセンブリを更新した場合、問題が発生することがあります。このシナリオが必要な場合は、UDT アセンブリでインクリメンタル バージョン セマンティクスを使用することで、この問題を回避できます。
この問題を解決するには
設定として使用するユーザー定義型がクラス ライブラリに存在する場合、ライブラリをインクリメンタル方式でバージョン化して問題を軽減します。ユーザー定義型が EXE に存在する場合は、IDE を閉じ、再起動して UDT への変更を有効にする必要があります。
