kkamegawa's weblog

Visual Studio,TFS,ALM,VSTS,DevOps関係のことについていろいろと書いていきます。Google Analyticsで解析を行っています

.NET Framework 4.0 BCLの続き

id:kkamegawa:20081106:p1の続き
id:NyaRuRu wrote:

>プロセス内で異なるバージョンのCLRがロードできるようになるのはうれしいなぁ。
>.NET Framework 1.1とか特に…(まだ使うことがあるのです)

In Process Side-by-Side ですが,確か CLR 1.x 世代はサポート外っす.

詳しくは Microsoft .NET Framework: CLR Futures のプレゼンの 10 ページ目とか.
http://channel9.msdn.com/pdc2008/PC49/
http://mschnlnine.vo.llnwd.net/d1/pdc08/PPTX/PC49.pptx

ありがとうございます。サポートライフサイクルが終わった*1.NET Framework 1.1はサポートされなくても仕方ないのか…。
Hosting API上に.NET Framework 4.0とCLR 2.0ベースの2.0〜3.5SP1までをHosting API経由で呼び出すという実装ですか。ふむ。
それぞれのCLR製のAdd-inでそれぞれの〜.exe.configファイルが必要になるような場合、それぞれ勝手につくれじゃぁちょっとかわいそうだから、この辺もなにかライブラリ側というか、サポートするようなフレームワークがあるといいかもね。
川俣さんから頂いたトラックバック
System.IO名前空間のメソッドでファイル一覧を得るときに列挙インターフェースが欲しい理由 【▲→川俣晶の縁側→ソフトウェア→技術雑記】
一万個くらいのファイルがあるフォルダに対してGetFiles()は確かに想定していない話でした。というか、システム上、作られないようにできるだけ考えておきますが、想像の斜め上のことをやってしまう方は確かにいます。
Windows NT 3.1登場時点から「一つのフォルダに数千個くらいファイルがあると途端に遅くなる」という痛い経験もしまた…ちなみにDLLも一つのフォルダに多く存在していると、ロードが遅くなるという話をどこかで聞いたか読んだ気がします。今現在Vista SP1のsystem32フォルダにあるdllは1800くらいですね。

*1:ただし、Windows Server 2003にインストールされている.NET Framework 1.1はWindows Server 2003のライフサイクル終了までサポート