トップ回答者
.Net Framework 2.0, 3.0, 3.5でsystem.dllは共通?

質問
-
外池です。確認できれば・・・、と思うことが1つあります。.Net Framework 2.0から、3.0、3.5とバージョンが上がりましたが、これらは機能の追加のようです。
で、例えばsystem.dllは.Net Framework 2.0にしかありません。ということは、3.0や3.5でも、system.dllで提供されるクラスやそのメンバーについては、2.0と同じ、ということになりましょうか? また、3.0や3.5のドキュメントでsystem.dllのクラスやそのメンバーに関する記述がありますが、2.0のドキュメントに比べて追記されている内容は、2.0に遡って適用されると考えて良いのでしょうか?
具体例としてまたNetworkStreamを引用しますが、
3.0や3.5のドキュメントには、Readがただ1つのスレッド、Writeがまた別のただ1つのスレッドから呼び出されているのであれば、お互いに干渉することは無い、呼び出しをシンクロさせる必要はない、と明記されています。この記述は2.0のドキュメントにはありませんが、しかし、実際には2.0でもこのような動作を期待できる・・・、のでしょうか?
(ホームページを再開しました)
回答
-
同じパス、同じアセンブリバージョンにはなりますが、ファイルバージョンは異なります。
.NET Framework 3.5 には .NET Framework 2.0 SP1 が、.NET Framework 3.5 SP1 には .NET Framework 2.0 SP2 が含まれています。
このとき、一部のアセンブリは新しいプロパティ、メソッドが追加されていたり、不具合が修正されていたりします。
こういったこともあるので、細かい挙動に差がないとは言い切れません。たとえば、System.Windows.Forms.dll は昔からありますが、2.0 SP1 でプロパティが増えている事例があります。
http://msdn.microsoft.com/ja-jp/library/system.windows.forms.filedialog.autoupgradeenabled(VS.90).aspxただ、目的とされている NetworkStream がどうかは存じません。
記載が拡充されただけかもしれません。
質問スレッドで解決した場合は、解決の参考になった投稿に対して「回答としてマーク」のボタンを押すことで、同じ問題に遭遇した別のユーザが役立つ投稿を見つけやすくなります。- 回答としてマーク 外池 2010年8月29日 3:13
-
もう少し端的に…mscorlib.dllのDateTimeOffset構造体 は.NET Framework 2.0 SP1で追加された型なので、SPなしには存在しません。
本題の「Readがただ1つのスレッド、Writeがまた別のただ1つのスレッドから呼び出されているのであれば、お互いに干渉することは無い、呼び出しをシンクロさせる必要はない」はどこの記述でしょうか? 記述そのものはまぁ構いませんが、気になるのは、NetworkStreamクラスとして干渉しなかったとしても、プロトコル的に通信相手が干渉しないとは限りません。(一通り応答を受信してからリクエストを送信しないとエラーになる、等)
その点は理解した上で、通信処理の実装方法について検討されているのでしょうか?- 回答としてマーク 外池 2010年8月29日 3:14
すべての返信
-
同じパス、同じアセンブリバージョンにはなりますが、ファイルバージョンは異なります。
.NET Framework 3.5 には .NET Framework 2.0 SP1 が、.NET Framework 3.5 SP1 には .NET Framework 2.0 SP2 が含まれています。
このとき、一部のアセンブリは新しいプロパティ、メソッドが追加されていたり、不具合が修正されていたりします。
こういったこともあるので、細かい挙動に差がないとは言い切れません。たとえば、System.Windows.Forms.dll は昔からありますが、2.0 SP1 でプロパティが増えている事例があります。
http://msdn.microsoft.com/ja-jp/library/system.windows.forms.filedialog.autoupgradeenabled(VS.90).aspxただ、目的とされている NetworkStream がどうかは存じません。
記載が拡充されただけかもしれません。
質問スレッドで解決した場合は、解決の参考になった投稿に対して「回答としてマーク」のボタンを押すことで、同じ問題に遭遇した別のユーザが役立つ投稿を見つけやすくなります。- 回答としてマーク 外池 2010年8月29日 3:13
-
NetworkStream クラス (System.Net.Sockets)
3.0 のドキュメントにも無いみたいですが。
3.5 をインストールすると、同時に 2.0/3.0 に SP1 が当たります。この SP で実装が変わった可能性があります。
-
もう少し端的に…mscorlib.dllのDateTimeOffset構造体 は.NET Framework 2.0 SP1で追加された型なので、SPなしには存在しません。
本題の「Readがただ1つのスレッド、Writeがまた別のただ1つのスレッドから呼び出されているのであれば、お互いに干渉することは無い、呼び出しをシンクロさせる必要はない」はどこの記述でしょうか? 記述そのものはまぁ構いませんが、気になるのは、NetworkStreamクラスとして干渉しなかったとしても、プロトコル的に通信相手が干渉しないとは限りません。(一通り応答を受信してからリクエストを送信しないとエラーになる、等)
その点は理解した上で、通信処理の実装方法について検討されているのでしょうか?- 回答としてマーク 外池 2010年8月29日 3:14
-
外池です。みなさん、コメントありがとうございます。
2.0に加えて、3.0、3.5とインストールしてやっても、System.dllはひとつのものを共有していること、また、途中でバージョンアップされていること、よく理解できました。
佐祐理さんのご指摘についてですが、NetworkStreamのドキュメントの記述ですが、英語版のものを見ております。
http://msdn.microsoft.com/en-us/library/system.net.sockets.networkstream(VS.90).aspx
3.5で以下のパラグラフが追加されています。「Read and write operations can be performed simultaneously (中略) there will be no cross-interference between read and write threads and no synchronization is required. 」
あと、ご懸念されている点については、大丈夫です。非同期動作を行うように検討しているのは、受信待機の部分だけでして、もっと高いレベルのプロトコルはきちんと標準的なもの(RFC)に従うようにプログラムすることにしていますので。
話題が発散してしまいますが、TcpClientのCloseメソッドの説明のうち、連動してNetworkStreamもCloseされるのかどうかについて、2.0、3.0、3.5の記述が変化して、かなり違った内容になってます。
(ホームページを再開しました)