web-dev-qa-db-ja.com

.NET 2.0アプリケーションで.NET 4.0ライブラリを使用できますか?

.NET 2.0アプリケーションで.NET 4.0ライブラリを使用すると、いくつかの問題が発生します。私はWindows DLLであるため、他の.NETアプリからもアクセスできるように思われていました。これはそうではありませんか?両方の環境でのアプリケーションのサポートに関する推奨事項はありますか?

[〜#〜] edit [〜#〜]:ターゲットシステムに.NET 4.0 Frameworkをインストールする必要があることを理解していますが、これができない/すべきでない他の理由があります働く?

[〜#〜] edit [〜#〜]:おそらくもっと具体的だったはずです。現在、.NET 2.0(正確にはASP.NET)で記述された大規模で複雑なアプリケーションがあります。 .NET 4.0で作成している新しい統合ツールとワークフロー項目のセットがあります。 4.0で作成されたライブラリの1つを.NET 2.0プロジェクト(現在VS2008)に追加し、そのメソッドのいくつかを利用したいと考えました。これを行うと、問題、多くの場合、メモリに関連する不可解なエラーが発生します。

最終的には、EarwickerとBrian Rasmussenの両方が正しいようです。私はCOMを介して物事を公開することにあまり熱心ではないので(これが技術的にCOMであるかどうかはわかりませんが、関係ありません)、2つは「互換性がない」という考えに固執し、他の手段を検討します。特定のニーズに基づいています。長期的には、.NET 2.0コードを4.0に移行する予定です。

30

はい、これは完全に可能です。 4.0で記述されたコンポーネントをCOMオブジェクトとして公開するだけです。 2.0ホスティングアプリケーションは、それらをCOMオブジェクトとして使用するだけであり、それらがネイティブであるか、2.0、4.0であるかどうかはわかりません。 COMは、両方のランタイムバージョンが同じように実装する必要がある共通のインターフェイスです。

4.0の新しいインプロセスSxSサポートは、4.0ベースのCOMオブジェクトが読み込まれると、2.0で実行するのではなく、必要なランタイムを取り込むため、両方のランタイムが独自のオブジェクトを管理するプロセスに存在することを意味します。それらの間でCLRオブジェクトを直接渡すことはできませんが、COMインターフェイスを渡すことができ、CLRはオブジェクトをCOMインターフェイスで透過的にラップします。

両方のバージョンの単一の相互運用機能アセンブリを作成できるかどうかはわかりません。ただし、2.0のC#で相互運用機能アセンブリを記述し、それを.tlbにエクスポートしてから、4.0のアセンブリにインポートすることができます。これにより、同一のCOMインターフェイスを記述する2つの一致する相互運用機能アセンブリが提供されます。 (または、各バージョンのアセンブリプロジェクトで同じC#ソースをビルドするだけです)。

ボーナス更新:結果のアプリケーションはCOMベースですか(問題が発生した場合)?

見方次第です。コンポーネントの作成者は、それらをCOMコンポーネントとして作成します。したがって、ホストアプリケーションはそれらをCOMコンポーネントとして見つけてロードする必要があります。これは、GAC、レジストリ、またはSxSマニフェストをいじくり回すことを意味します。これは、コンポーネントの作成者にアセンブリを特定のディレクトリにドロップしてリフレクションでロードできるように指示するよりもはるかにクリーンではありません。

また、実行時に影響があります。ホストがコンポーネントへの参照を持っている場合、1つではなく3つのオブジェクトが含まれます。ホストにはRCWへの参照があり、RCWには、CCWによって実装されたCOMインターフェイスへのポインターがあり、実際のコンポーネントへの参照を保持しています。真ん中のCCWは参照カウントされたCOMオブジェクトであり、ホストのRCWにはCCWでReleaseを呼び出すファイナライザがあり、破棄されると、生存しているGCRootの割り当てを解除します実際のコンポーネント。

これは、コールバックポインタなどの配置が十分に複雑な場合、システムは循環参照カウントの問題を引き起こす可能性があることを意味します。オブジェクトの切断された「アイランド」がすべて相互に参照を保持しているため、割り当てが解除されることはありません。

23

バージョン4.0は単なる追加のアセンブリではないことに注意してください。このバージョンでは、ランタイム自体も変更されています(新しい同時GCモード、スレッドプールへの多くの変更、mscorwks.dllはclr.dllと呼ばれるようになりました)。

10
Brian Rasmussen

私は基本的にダニエルが提案した投稿を公開しました。

。NET 4ベースの使用方法DLL .NET 2ベースのアプリケーションから

ソースコードと説明: http://code.msdn.Microsoft.com/Using-a-NET-4-Based-DLL-bb141db

10
arik

使い方によっては可能かもしれません。 .Net 4.0では、In Process Side by Side Execution(InProc SxS)のオプションがあります。これにより、同じプロセス空間で2つの異なるバージョンのCLRをホストできます。これは ここで説明 です。

これをあなたの状況で利用できるかどうかはわかりません。私はあなたを助ける直接的な経験はありません。

scenarios を使用できる場合があります。

3
softveda

CLR 4に追加されたインプロセスside-by-side機能は、.NET2.0アプリケーションで.NET4.0ライブラリを使用したいので、この場合は役に立ちません。私が理解している限り、4.0のCLRは2.0同じプロセス.

1
Derar

.NET 4用にコンパイルされたアセンブリには、.NET 2.0にはない他の.NET 4フレームワークライブラリへの参照が含まれます。

アプリケーションに.NET 2.0との互換性を持たせたい場合、Visual Studio 2005または target を使用して、Visual Studio 2008または2010を使用している場合はプロジェクトを.NET 2.0にできます。もちろん、 .NET 2.0へのプロジェクトでは、.NET 3.5/4機能を利用できません。

0
Daniel Melo

.net 4.0コンポーネントを使用していて、APIを参照できなかった私のアプリケーションにも同様の問題がありました。
これを解決するために、.net 4.0プロジェクトを参照する新しいクラスライブラリプロジェクトを作成し、.net 2.0プロジェクトからその新しいアセンブリを呼び出しました。 .net 2.0プロジェクトで使用するために、.net 4.0プロジェクトから返されたデータをマッピングしました。
それで私の問題は解決しました。

0
savvyBrar