8月に.NET 3.5 SP1がリリースされた(参考記事)。理論上はCLR 2.0、3.0および3.5の旧バージョンに依存しているアプリケーションを破壊しないことになっている。しかし、オープンソースプロジェクト、 Castle(リンク)などいくつかのアプリケーションは壊れているという報告がある。
MicrosoftのSenior Program ManagerであるScott Hanselman氏(リンク)は、.NET 3.5 SP1での問題点(リンク)について書いた。最初に、氏は「.NET Framework 3.5 SP1は、2.0アプリケーションを壊してしまうのか?」と尋ね、それから「それは九分九厘ない」と答えた。3.5 SP1がCLR 2.0以降に依存している既存の.NETアプリケーションに影響を及ぼすべきではない理由を説明した後、氏は「エッジケースに当たった」ことを認めてい る。社内テストを実施して、SP1が何も破壊しないようにするように忠告している。
SPのように何かが破壊する可能性がある場合、整合性テストを実施し、エッジケースに当たっていないようにする。
Castle Projectの創設者であるHamilton Verissimo de Oliveira氏(リンク)は、今年Microsoftに入社したが(参考記事)、Castleを破壊しているSP1(リンク)に不満を漏らした。氏は、何が壊れていてそれに対処するた めにおこなったことを説明している。
- 汎用インターフェイス/メソッドのプロキシを作成する際、SPはDynamicProxy 2を破壊した。
- エッジケースに対処するために、例外を投げ始めたコードが用意されている。
- Breaking DynamicProxyは、 それを使用するあらゆるものを破壊する(Rhino Mocks、Castle Windsor、NHibernateおよびMoq - 今思いつくのは、これらである)。
- 最近、問題を確認しDynamicProxyコードを変更し、これらのメソッドを使用しないようにした「r5323：(1つを除く)すべてのテストがパスするようにGetOptional/RequiredCustomModifiers呼び出しを無効にする」。
Hamilton氏は、以下のように提案している。
あるCLRのチームが、SP 1でCastleテストケースを実行することを決めていたなら、それを見つけていただろう。Monoは、プラットフォームの実装をテストするために外部テ ストケースリポジトリを統合する。MSは、ライセンスが問題ではない少数のOSSプロジェクトに対して、同様のことをおこなう場合がある。法的な問題のた めにそれが不可能な場合、CLRチームはOSSチームとの通信を簡素化し、迅速にフィードバックを得る。
Scott Hanselman氏は、Windows Updateを通じて11月頃にSP 1が量産される前には、.NET 3.5 SP1のパッチが完成していることを約束している。そうなると、現在.NET 2.0を搭載しているすべてのマシンは、3.5 SP1にアップグレードされることになる。その間にも、.NET 3.5 SP1で問題を抱えている人はMicrosoftのConnect(リンク)サイトにぜひともそのバグを掲載して欲しい。
原文はこちらです：http://www.infoq.com/news/2008/10/.NET-3.5-SP1-Breaks-Applications