none
.Net Framework 2.0, 3.0, 3.5でsystem.dllは共通? RRS feed

  • 質問

  • 外池です。確認できれば・・・、と思うことが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でもこのような動作を期待できる・・・、のでしょうか?


    (ホームページを再開しました)
    2010年8月27日 15:07

回答

  • 同じパス、同じアセンブリバージョンにはなりますが、ファイルバージョンは異なります。
    .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
    2010年8月27日 16:24
    モデレータ
  • もう少し端的に…mscorlib.dllのDateTimeOffset構造体 は.NET Framework 2.0 SP1で追加された型なので、SPなしには存在しません。

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

    • 回答としてマーク 外池 2010年8月29日 3:14
    2010年8月27日 20:58

すべての返信

  • 同じパス、同じアセンブリバージョンにはなりますが、ファイルバージョンは異なります。
    .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
    2010年8月27日 16:24
    モデレータ
  • NetworkStream クラス (System.Net.Sockets)

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

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

    2010年8月27日 16:31
  • もう少し端的に…mscorlib.dllのDateTimeOffset構造体 は.NET Framework 2.0 SP1で追加された型なので、SPなしには存在しません。

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

    • 回答としてマーク 外池 2010年8月29日 3:14
    2010年8月27日 20:58
  • 外池です。みなさん、コメントありがとうございます。

    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の記述が変化して、かなり違った内容になってます。


    (ホームページを再開しました)
    2010年8月28日 0:21