Enterprise Services を使用して、COM+ コンポーネントの形式でサービスを構築する必要があります。
サービスは現在稼働中です。文字列を取得してスペル チェックを行い、文字列を返します。
私の質問は：
このコンポーネントは .NET 1.1 でコンパイルされましたが、私の環境はまもなく .NET 3.5 に変更されます。コードを .NET 3.5 (実際には 2.0) でコンパイルすると、何かメリットがありますか? .NET3.5 でコンパイルするだけでパフォーマンスに変化はありますか?
私は .NET3.5 機能 (または WCF) を使用していないことに注意してください。
助けてくれてありがとう。
CLR とライブラリには最適化が行われています (たとえば、起動が高速化されています) が、実際の速度の違いが見られるかどうかを判断するのは困難です。文字列操作は、メモリ割り当てがガベージ コレクターへのプレッシャーを意味することを意味するため、3.5 では少し改善されるはずです。
テストと測定によってのみ本当の答えが得られます。申し訳ありません。
アセンブリのロードとコードのJITコンパイルは、.NET1.0ですでに大幅に最適化されています。.NETアプリの起動時間に直接影響するため、非常に重要です。2.0CLRはこれを劇的に改善していません。
ただし、.NET3.5SP1ではセキュリティポリシーが更新されました。アセンブリの場所が信頼されている場合、アセンブリの厳密な名前はチェックされなくなりました。正確なルールはここに記載されています。これにより、ウォームスタートが40％も速くなります。それは楽観的な数字です、YMMV。
ジェネリック コレクションなどの新しい機能を使用するコードを変更しない場合は、あまり変更されません。また、ほとんどの新しい OS には .NET 1 または 1.1 がインストールされておらず、.NET 2 ランタイム (3.5 でも使用されているランタイム) を使用してコードを実行します。したがって、ランタイムの新しいバージョンで強化されている可能性のある、より優れた jitting、interop などの恩恵を受ける必要があります。
通常のアプリケーションの場合、使用するフレームワークのバージョンを構成ファイルで指定できるため、1/1.1 アプリケーションに対しても .NET 2 ランタイムの使用を強制できます。ただし、これがCOMでアクティブ化されたものに対してどのように機能するか、およびどのように機能するかはわかりません。
スピードに関しては - たぶん (ただし、.Net 3.5 は 1.1 よりもさらに大きいことに注意してください。LINQ、WCF、CF、WPF などの新しいテクノロジが含まれているためです)。
展開 - 最新の Windows OS には、システムの機能として .Net Framework 3.0+ が既に利用可能であるため、.net 3.5 が適しています。
メンテナンス \ 今後の検討事項 - .net 3.5. 今すぐ .Net 3.5 に移行することをお勧めします。そのため、ソフトウェアを変更する必要がある場合は、利用可能なより新しいテクノロジの恩恵を受けることができます...