現在約20の.NETFramework2.0アプリケーションをホストしている本番アプリケーションサーバーに.NETFramework3.5をデプロイする場合、どの程度の懸念を払う必要がありますか？
.NETFramework3.5を環境にロールアウトするという私の要求に抵抗があります。自信を持って回帰テストを行うことはできません。また、各アプリケーションを自信を持ってテストするためのリソースもありません。
.NET Framework XXは、主要な設計目標として、1.0、1.2、2、3、3.5などを同じマシンに展開できるように構築および証明されており、相互作用が高いと確信しています。バージョンは以前のバージョンを壊しません。
私はITコミュニティで報告されている「重大な変更」を見つけようとしましたが、これまでのところ非常に少数の例しか見つかりませんでした。そのため、最小限のテストでこのランタイムの展開を迫る傾向があります。
この状況で.NET3.5を展開するためのこのアプローチについて、どの程度懸念されていますか。
私の懸念のレベルは非常に低いです。3.5フレームワークが既存の2.0アプリケーションと対話する唯一の方法は、3.5のインストール中に2.0CLRに適用されたサービスパックによるものです。つまり、サービスパック1。したがって、インストール後、以前のすべてのアプリはCLR2.0SP1とCLR2.0で実行を開始します。
それで、本当にこれはあなたがサービスパックにどれくらいの自信を持っているかという問題ですか？
これは、サービスパックへのリンクとそれらが修正したバグのリストです。すべてのバグ修正は、ある意味で重大な変更であり、アプリケーションの動作に影響を与える可能性があります（そうでない場合は、なぜ修正するのですか？）。
.Net 2.0は、実際には.Net3.5のサブセットにすぎません。
これらは両方ともCLR2.0の上に構築されています
3.0 Foundationライブラリ（WF、WCF、WPF）が追加され、3.5は追加機能のもう1つのロールアウトでした。全体として、マシンで完全にクレイジーなことをしていなければ、まったく問題はないはずです。
私はあなたの懸念を理解しており、通常、最初に非本番環境のサーバーでできるだけ多くのテストを行うことをお勧めします。
ただし、そうは言っても、.NET3.5のコアランタイムコンポーネントは.NET2.0のコンポーネントと同じです。バージョン3.5は、基本的に.NET v2.0であり、その上に追加のライブラリがあります。
あなたが言うように-フレームワークは非常に幸せに共存するように設計されているので、それはすべて大丈夫なはずです。
確かに、ライブ環境での展開に問題はありませんでした。
免責事項：上記のすべては私の経験からのものです-それがすべてうまくいかなくても私を責めないでください！; o）
複数のドットネットバージョンが同じマシン上に存在する可能性があり、ドットネットアセンブリは実際にはそのマニフェストにターゲットフレームワークを保持しています。したがって、アプリケーションが2.0以前でコンパイルされていて、そのバージョンがマシンに存在する場合は、まったく問題はありません。これは、ドットネットフレームが最初にターゲットにしたものです。並列実行とDLL地獄の問題の排除。
ただし、上位互換性が問題になることはありませんでした...アセンブリがバージョン2.0でコンパイルされている場合、それ以降のバージョンでも完全に実行されます...ただし、それでも問題が発生する場合は、MS：Pのせいにする必要があります。
新しいバージョンの場合、幸いなことに、コンパイル時に非推奨のチェックを実施するだけで十分に成熟しています。実行時には問題はありません。
フレームワークでの新機能の追加後に発生するエラー状態について（アプリケーションの回帰テストについて言及しているように）...非常にまれなものですが、常にチャンスがあります。ただし、ドットネットフレームワークの実行オプションを並べて使用する場合は、アセンブリが読み込まれ、マシンに存在する場合はターゲットのフレームワークで実行されます。
私はここのみんなに同意しますが、コメントを1つ追加します。Service Pack1を使用して.NET3.5をインストールする場合、ローカルハードドライブで実行されている場合と同じように、ネットワーク共有上の.NETコードを完全なアクセス許可で実行できるようにする追加のアクセス許可がマシンに自動的にプッシュされます。 。それが問題になる場合は、権限の制限を検討することをお勧めします。