.Net Framework 2.0, 3.0, 3.5でsystem.dllは共通？

Question

外池です。確認できれば・・・、と思うことが１つあります。.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がただ１つのスレッド、Writeがまた別のただ1つのスレッドから呼び出されているのであれば、お互いに干渉することは無い、呼び出しをシンクロさせる必要はない、と明記されています。この記述は2.0のドキュメントにはありませんが、しかし、実際には2.0でもこのような動作を期待できる・・・、のでしょうか？

---

（ホームページを再開しました）

Answer 1

同じパス、同じアセンブリバージョンにはなりますが、ファイルバージョンは異なります。
.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 がどうかは存じません。
記載が拡充されただけかもしれません。

---

質問スレッドで解決した場合は、解決の参考になった投稿に対して「回答としてマーク」のボタンを押すことで、同じ問題に遭遇した別のユーザが役立つ投稿を見つけやすくなります。

Answer 2

NetworkStream クラス (System.Net.Sockets)

3.0 のドキュメントにも無いみたいですが。

3.5 をインストールすると、同時に 2.0/3.0 に SP1 が当たります。この SP で実装が変わった可能性があります。

Answer 3

もう少し端的に…mscorlib.dllのDateTimeOffset構造体 は.NET Framework 2.0 SP1で追加された型なので、SPなしには存在しません。

本題の「Readがただ１つのスレッド、Writeがまた別のただ1つのスレッドから呼び出されているのであれば、お互いに干渉することは無い、呼び出しをシンクロさせる必要はない」はどこの記述でしょうか？ 記述そのものはまぁ構いませんが、気になるのは、NetworkStreamクラスとして干渉しなかったとしても、プロトコル的に通信相手が干渉しないとは限りません。（一通り応答を受信してからリクエストを送信しないとエラーになる、等）
その点は理解した上で、通信処理の実装方法について検討されているのでしょうか？

Answer 4

外池です。みなさん、コメントありがとうございます。

2.0に加えて、3.0、3.5とインストールしてやっても、Ｓｙｓｔｅｍ.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. 」

あと、ご懸念されている点については、大丈夫です。非同期動作を行うように検討しているのは、受信待機の部分だけでして、もっと高いレベルのプロトコルはきちんと標準的なもの（ＲＦＣ）に従うようにプログラムすることにしていますので。

話題が発散してしまいますが、TcpClientのCloseメソッドの説明のうち、連動してNetworkStreamもCloseされるのかどうかについて、2.0、3.0、3.5の記述が変化して、かなり違った内容になってます。

---

（ホームページを再開しました）