異なるバージョンのSilverlightアセンブリのバージョン番号が同じであるのはなぜですか？

異なるバージョンのSilverlightアセンブリのバージョン番号が同じであるのはなぜですか？異なるバージョンのSilverlightアセンブリのバージョン番号が同じであるのはなぜですか？

Location: ...\Silverlight\v3.0\System.Core.dll 
Name: System.Core, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e 

Location: ...\Silverlight\v4.0\System.Core.dll 
Name: System.Core, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e 

Location: ...\Silverlight\v4.0\Profile\WindowsPhone\System.Core.dll 
Name: System.Core, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e

標準の.NETは、異なるバージョン番号

Location: ...\Framework\v4.0.30319\System.dll 
Name: System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 

Location: ...\Framework\v2.0.50727\System.dll 
Name: System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089

出典

2010-12-14 Simon

私はいつもそれを知りたかった。私は何かが欠けているに違いないと思った。 –

それは良い質問です。 –

を有しているがSystem.Coreの2.0.5.0バージョンを使用してからのSilverlight 4のフレームワークを止めるものは何もありません。 .NET 3.5フレームワークは、System.Webのバージョン2.0に付属しています。ただし、.NET 4フレームワークには新しいバージョンのSystem.Coreが同梱されています。

出典

2010-12-14 03:01:02

あなたはその点を見逃していると思います。すべてのSilverlightファイルのすべてのバージョンは同じです。それらははっきりとは異なるファイルではあるが。 – Simon

バージョン番号を変更してチェックリストを持たないことを忘れている開発チームだと思いますが、私は100％確実ではありません。この作業を自動化するメカニズムはありません。中央コンパイラはありません。この開発グループの各ユーザーは、公開キートークンで厳密な名前を持つ限り、このコードアセンブリをコンパイルできます。私はこのテーマの専門家からの完全な答えに興味があります。

出典

2010-12-14 03:35:51

これは、MSが出荷するアセンブリです。確かに、MS開発チームがバージョン番号を変更するのを忘れたとは思わないでしょうか？ – Gabe

成熟した開発プロセスには、チーム全体の変更のためにアセンブリのコンパイルを自動化する[ビルドシステム]（http://en.wikipedia.org/wiki/Build_automation）があります。したがって、概念的には集中型コンパイラがあります。個々の開発者は、実際にリリースされるアセンブリを作成する責任はありません。ビルドシステムによってこれらが生成されます。 –

本当ですか？私は、彼らが強力なキーを使用してアセンブリを作成し、アセンブリに強いキーを追加し、その固有のIDの下にその強力なキーを格納したと思った。その一意のIDは公開鍵トークンです。バージョンは、そのプロジェクトのアセンブリを最後にコンパイルした人が設定します。 Signleソリューションに複数のプロジェクトを含めることができるため、プロジェクトごとに独自の署名付きアセンブリを持つ可能性があります。ビルドシステムはクールに聞こえる、私はそれを調査する必要があります。情報をありがとう。 –

たぶん彼らは、開発者がSliverlightフレームワークの異なるバージョンをターゲットにするSilverlightアプリケーションを再コンパイルする必要はありません...

出典

2010-12-18 14:55:30 Kii

Windowsの電話機アセンブリでは、それを再コンパイルしたかのように動作しません。 – Simon

まったく同じことは、デスクトップ用（System.dllのような）基本クラスライブラリで起こりました.NET 2.0、2.0SP1,2.0SP2,3.0,3.0SP1,3.5,3.5SP1のバージョンは、すべて同じ[AssemblyVersion]、2.0.0.0です。 .NET 4.0以降、このバージョンは4.0.0.0にバンプされました

アセンブリバージョンはアセンブリの公開インターフェイスを表します。他のアセンブリからアクセス可能な型メンバーの急激な変更には、新しい[AssemblyVersion]が必要です。そのためには、これらの型を使用して再コンパイルするクライアントコードが必要です。あなたが言及したSystem.Core.dllのバージョンを確認しました。組み立てのためのReflectorエクスポート出力を介した苦しいスローグのビット。プライベートクラスと内部クラスとメソッドには多くの変更があります。しかし、ではなく、のパブリックなもの、同じタイプとメソッド。

StrongBoxクラスはバージョン4.0でデフォルトのコンストラクタを取得しました。「このAPIは.NET Frameworkインフラストラクチャをサポートしており、コードから直接使用するためのものではありません」とドキュメント化されています。具体的には、Silverlightでは4.0をターゲットとするアプリケーションは、デスクトップの場合とは異なり、偶然、そのクラスの3.0バージョンを見ないだろう。

出典

2010-12-18 20:31:51

ハンス。 Silverlight 3とSilverlight 4は、同じランタイムであると主張できるので、これは意味をなさないかもしれません。しかし明らかに異なる公開APIであるWindows Phone Assembliesのためのものではありません。 – Simon

私はそれをチェックする必要はありませんが、なぜそれが違うのか分かりません。ただSilverlight。 –

.NETの場合、署名付き（.snk）アセンブリの場合、アセンブリのバージョン番号を変更しない最初の理由は、アセンブリの厳密な名前がそのまま維持されることです。このように、.configファイルやカスタムポリシーを邪魔することなく、アセンブリへの参照を使用してビルドされたクライアントは、依然として不満なくロードすることができます。

既定では（assemblies redirectionsを定義しないで）、バージョンを変更すると、アセンブリの厳密な名前も変更され、以前のバージョンに対して既存のアセンブリビルドがすべて実行されなくなります。

もちろん、バージョンを変更しない場合は、同じクライアントを別のクラスまたはメソッドのシグネチャで壊さないように注意する必要があります。

ほとんどの場合、開発者は同じバージョンを維持する傾向があります。永遠に可能な場合はCoreCLR（SilverlightのCLR）と.NET CLRの場合も同様です。

しかし、.NET CLRの場合、バージョンを変更したという事実は、実際には既存の.NETアプリケーションにいくつかの問題を引き起こします。時には、既存の.NET 2つのアプリケーションは、.NET 4のコンテキストで.configファイルにこれを追加する必要があります。

<configuration> 
    <startup> 
    <supportedRuntime version="v4.0.30319" /> 
    </startup> 
</configuration>

あなたはこのすべては、シーンの背後にすることができますどのように複雑な説明この記事を見ることができます：Version Compatibility in the .NET Framework

出典

2010-12-21 16:51:53

これは、Silverlightアセンブリが同じであることを説明するかもしれませんが、SilverlightとWP7アセンブリが同じバージョン番号を持つ理由を説明していません。 – Simon

SLのために構築されたアセンブリが、書き換えなしにWP7と幾分互換性がある場合、それは説明することができます。 –

異なるバージョンのSilverlightアセンブリのバージョン番号が同じであるのはなぜですか？

答えて

関連する問題