2012-10-04 9 views
18

私が知っている限り、以下のタイプのほとんどは現在、常にmscorlibおよび/またはSystem.dllで定義されています。System.IO.dllのポイントは何ですか?

しかし、v4フレームワークディレクトリ(4.5がインストールされていて、それがバニラのv4にも存在するかどうかはわかりません)を見ると、System.IO.dllというアセンブリが見つかります。

リフレクターで調べると、実際のコードは表示されません。私は見つけることができるすべては、次のエントリのとおりです。

[assembly: TypeForwardedTo(typeof(BinaryReader))] 
[assembly: TypeForwardedTo(typeof(BinaryWriter))] 
[assembly: TypeForwardedTo(typeof(EndOfStreamException))] 
[assembly: TypeForwardedTo(typeof(FileNotFoundException))] 
[assembly: TypeForwardedTo(typeof(InvalidDataException))] 
[assembly: TypeForwardedTo(typeof(IOException))] 
[assembly: TypeForwardedTo(typeof(MemoryStream))] 
[assembly: TypeForwardedTo(typeof(SeekOrigin))] 
[assembly: TypeForwardedTo(typeof(Stream))] 
[assembly: TypeForwardedTo(typeof(StreamReader))] 
[assembly: TypeForwardedTo(typeof(StreamWriter))] 
[assembly: TypeForwardedTo(typeof(StringReader))] 
[assembly: TypeForwardedTo(typeof(StringWriter))] 
[assembly: TypeForwardedTo(typeof(TextReader))] 
[assembly: TypeForwardedTo(typeof(TextWriter))] 

は、すべてのバックmscorlibに向いて(私が思うに、それらのすべてをチェックしていません)。私は周りを見てきましたが、これらのタイプがmscorlibにないフレームワークバージョン(例:シルバーライト、コンパクトなど)を見ることはできません。ですから、なぜこのアセンブリが存在するのか(なぜ今なぜなのか)誰にも分かりますか?

+2

私は推測できますが、将来のリリースでの移植性Rxでは、Bart de Smetはアセンブリ間の要素を取り除き、可能な限りプラットフォームの仕様を除外しました。 – rene

+0

vanilla v4には存在しないようです。 – AakashM

答えて

10

リファレンスアセンブリが見つかりました。 .NET> = 4.0を対象とする.NETプロジェクトでこのような参照アセンブリを使用してはいけないので、それは奇妙に思えるかもしれません。あなたは通常、あなたのdevマシンのC:\ Program Files(x86)\ Reference Assembliesディレクトリから取得します。しかし、コンパイラが使用される唯一のシナリオではありません。また、プログラムでSystem.CodeDomを使用する場合、またはXMLのシリアル化に依存する場合は、コンパイラを使用します。

具体的にはSystem.CodeDomとXMLのシリアル化は、コンパイラがユーザーのマシン上で実行されることです。特定の.NET Frameworkバージョンをターゲットにすることはできません。あなたのユーザのマシンには、あなたのマシンが持っているターゲットパックがありません。そのため、マシンにインストールされているバージョンがあれば入手できます。 C:\ Windows \ Microsoft.NET \ Framework \ v4.0.30319のファイルには、インストールされているバージョンと一致する参照アセンブリが含まれています。マシンが別の.NET 4.xリリースで更新されると、それらの参照アセンブリも同様に更新されます。

唯一可能なシナリオではなく、コマンドラインからビルドするときにも使用する可能性があります。または構築サーバー上で、VSライセンスを支払わないことにしました。非常に悪い考えです。または、ILMergeコマンドで、あまりにも悪い考えです。これらのシナリオはもっと面倒です。組み立てられたアセンブリが同じマシンにとどまっている限り、問題なく動作します。しかし、別のマシン(別のフレームワーク・バージョンがインストールされているマシン)に移動する場合はそうではありません。それはthis Q+Aに明白な不思議なランタイム例外を生成する可能性があります。

System.IO.dllはかなりエキゾチックです。 System.CodeDomをPCLアセンブリへの参照を使用して実行するときにのみ必要になります。その主な役割は、宣言を非表示にします。これは、選択したプロファイルでは使用しないでください。 WinRTを対象とするときにはこれらの型を使用できないため、System.IO名前空間は非表示にする必要があります。しかし、それ以外の型が含まれていない理由は、[TypeForwardedTo]はコンパイラにその型がデスクトップマシンでサポートされていることを他の場所で宣言することを指示します。mscorlib.dll

+0

私はこの回答を受け入れることについて矛盾しています。これは参照アセンブリではなく、他のコア、フレームワーク(非参照)アセンブリと並んで、 'C:\ Windows \ Microsoft.Net \ framework \ v4.0.30319'からのものであり、GACに格納されているアセンブリと同じです。したがって、パラグラフ1とパラグラフ5は正しくありません。パラグラフ4も目標を逃しています。v4.5に導入されたときには、それは従来の理由ではほとんどありません。しかし、パラグラフ3は正しいと思われる。 –

関連する問題