問題タブ [system.addin]

ClickOnce で System.Addins API を使用することによる煩わしいビルド プロセスがあります。System.Addins を使用するには特定のディレクトリ構造が必要であり、メイン プロジェクトはアダプター、ビュー、およびコントラクトを直接参照しないため、ClickOnce アーキテクチャではうまく機能しません。

ビルド プロセスの面倒な部分は、ポスト ビルド イベントを介して、アドイン コンポーネントの .dll をメイン アプリ プロジェクトのディレクトリにコピーし、それらのファイルをメイン プロジェクトから手動で参照する必要があることです。それらが含まれます。第一に、正しくビルドするにはビルドを 2 回繰り返す必要があります。第二に、ソース管理に干渉します (コピーしたアドイン dll ファイルをソース管理から除外する必要があります。そうしないと、それらに加えられた変更にはチェックアウトが必要になります)。

それで、私の質問は、このハックを回避する方法はありますか? よりエレガントなもの？

複数の AppDomains で実行される WPF UI の作成を検討しています。アプリ ドメインの 1 つはアプリケーションを実行し、残りの AppDomain は一連のユーザー コントロールとロジックをホストします。もちろん、この考え方は、これらのユーザー コントロールとロジックをメイン アプリケーションからサンドボックス化することです。

MAF/System.AddIn を使用してこれを行う例を次に示します。他の人はこれについてどのような経験をしていますか? このソリューションは、1 つのユーザー コントロール内で発生する可能性がある RoutedEvents/Commands をどのように処理し、これらを AppDomains 間で適切にシリアル化しますか? WPF リソースはどうですか? AppDomain 間でシームレスにアクセスできますか?

Managed Extensibility Framework（MEF）とManaged AddIn Framework（MAF、別名System.AddIn）は、非常によく似たタスクを実行するようです。このStackOverflowの質問によると、MEFはSystem.Addinの代わりになりますか？、両方を同時に使用することもできます。

どちらを使用するのか、もう一方を使用するのはいつですか。どのような状況で、両方を一緒に使用することを選択しますか？

Managed AddIn Framework（MAF、別名System.AddIn）を使用して作成されたアドインに構成設定を渡す必要があります。アドインのコンストラクターに設定パラメーターを設定できますか？

もう1つのオプションは、Initialize（）メソッドを作成することですが、アドインで作業を行う前に、このメソッドを呼び出すことを忘れないでください。

System.AddIn名前空間に実装された.NETFramework（現在は3.5 SP1を使用）によって提供されるAddInフレームワークの使用について質問があります。単純なアドインを使用してプロトタイプを作成します。このアドインは、WCFサービスのビジネスロジックでインスタンス化されます。

ビジネスロジックの実装（必要なコードのみが示されています）：

サービスの実装（必要なコードのみが表示されます）：

2つのユニットテストを作成しました。1つはビジネスロジックの直接メソッドを呼び出し、もう1つはWCFメソッドを呼び出します。直接呼び出しは正常に機能しますが、WCFからアドインをアクティブ化すると、次の例外が発生します。

「透過プロキシをタイプ'ERES.ConversionService.Contract.IConversionContract'にキャストできません

スタックトレース：

ConversionHostViewToContractAdapter_ConstructorInvoker（Object）at System.AddIn.Hosting.AddInActivator.AdaptToHost [T]（AddInTokenパイプライン、IContract addInContract）at System.AddIn.Hosting.AddInActivator.ActivateInAppDomain [T]（AddInTokenパイプライン、AppDomainドメイン、AddInControllerImplコントローラー、ブール）at System.AddIn.Hosting.AddInActivator.Activate [T]（AddInToken token、PermissionSet permitSet、String appDomainName）at System.AddIn.Hosting.AddInActivator.Activate [T]（AddInToken token、AddInSecurityLevel level、String appDomainName）atSystem。 AddIn.Hosting.AddInActivator.Activate [T]（AddInToken token、AddInSecurityLevel level）at System.AddIn.Hosting.AddInToken.Activate [T]（AddInSecurityLevel trustLevel）at ERES.ConversionService.BL.BusinessLayer.Execute（Object toConvert、Operation operation ）Cで：\ Documents and Settings \ kc \ My Documents \ Visual Studio 2008 \ Projects \ ConversionServiceSolution \ ERES.ConversionService.BL \ BusinessLayer.cs：line 44 at ERES.ConversionService.Service.Execute（Object toConvert、Operation operation）in C：\ DocumentsおよびSettings\kc \ My Documents \ Visual Studio 2008 \ Projects \ ConversionServiceSolution \ ERES.ConversionService \ Service.svc.cs：line 25 at SyncInvokeExecute（Object、Object []、Object []）atSystem.ServiceModel.Dispatcher.SyncMethodInvoker。 System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin（MessageRpc＆rpc）でInvoke（Object instance、Object [] input、Object []＆outputs）\ Documents and Settings \ kc \ My Documents \ Visual Studio 2008 \ Projects \ ConversionServiceSolution \ ERES.ConversionService \ Service.svc.cs：line 25 at SyncInvokeExecute（Object、Object []、Object []）atSystem.ServiceModel.Dispatcher。 SyncMethodInvoker.Invoke（Object instance、Object [] input、Object []＆outputs）at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin（MessageRpc＆rpc）\ Documents and Settings \ kc \ My Documents \ Visual Studio 2008 \ Projects \ ConversionServiceSolution \ ERES.ConversionService \ Service.svc.cs：line 25 at SyncInvokeExecute（Object、Object []、Object []）atSystem.ServiceModel.Dispatcher。 SyncMethodInvoker.Invoke（Object instance、Object [] input、Object []＆outputs）at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin（MessageRpc＆rpc）

何か助けはありますか？

よろしくAntonKalcik

更新： 私はこのコードでこれを回避することができました：

したがって、この場合、AddInはサービスselfと同じAppDomainでのみ実行できます。でもなぜか分かりませんか？

.net では、新しい AppDomain 内にアドインを作成できます。新しい AppDomain の作成は新しいことではなく、AppDomainSetup クラスを使用して、新しく作成された AppDomain のすべてのスタートアップ パラメーター (app.config の場所など) を指定できます。ただし、新しい AddInProcess (完全に新しいプロセス内で AddIn をインスタンス化する必要があることを指定) を使用して AddInToken をアクティブ化する場合、新しいプロセス内で AppDomain を作成するために使用される AppDomainSetup パラメーターに直接アクセスすることはできません。

これを行う方法はありますか?? 新しいアドインに、新しい app.config 設定や、AppDomain のさまざまなカスタマイズを強制的に使用できるようにする必要があります。

ここで助けてくれてありがとう...

ASP.NET および/または ASP.NET MVC アプリケーションで System.AddIn を使用する記事/例を知っている人はいますか?

System.AddIn を使用して、ASP.NET MVC アプリケーションを拡張可能にしようとしています。

堅牢なアドインアーキテクチャが必要なため、プロジェクトでMAFを使用したいと思います。それでも、他のアドインからアドインのメソッドを呼び出す必要があるところまで来ました。一部のアドインが他のアドインに依存している、または利用可能な場合は他のアドインの機能を使用するという柔軟な方法でこれを実現するにはどうすればよいですか。

たぶん、ホストプロセスを介した集約？

よろしくお願いします。

ウフク。

少なくとも7つのアセンブリが必要であり、Appdomain分離機能が機能し始める前に、アドインのデータモデルをリモート処理で処理できるデータ型に制限します。とても複雑です！System.AddInチームのブログは、COMのメンタルモデルを再作成しようとしていたことを示唆しています。このモデルは、そもそもよく理解できておらず、メリットが売りに出されていません。（COMが非常に優れている場合、なぜそれは死んでいるのですか？-レトリックの質問です。）レガシーCOMとミラーリングまたは相互運用する必要がない場合（VSTOがSystem.AddInを使用するように）、ロードをロードするいくつかのクラスを作成することは可能ですか？新しいAppDomain？

私は自分でディスカバリーコードを書くことができます、私は以前にそれをしました、そして私はGACのアセンブリを反復するのが好きではないので、素朴な実装はかなり速いです！

だから私の特定の質問は、AddInsがいくつかのコードリモーティングスニペットで提供するAppDomain分離を取得できますか？それらは何でしょうか？

WindowsFormsHost コントロールにラップされた Windows フォーム ベースのコントロールで発生していたメモリ リークの問題を解決するために System.AddIn を使用している WPF アプリケーションに取り組んでいます。アドインは、WindowsFormsHost のオーバーヘッドを回避するために、必要に応じて Windows フォーム ベースのコントロールをロードおよびアンロードするために使用されます。このオーバーヘッドは、WPF の現在のバージョンでアプリケーションが閉じられるまでハングアップし、Windows フォーム ベースのコントロールでメモリ リークが発生します。クリーンアップ ロジックが正しくありません。

私たちが直面している問題は、アプリケーションでアドインをロードおよびアンロードした後、WPF アプリケーションがアプリケーションの終了時に「無効なウィンドウ ハンドル」の Win32 例外をスローすることです。これは通常、重大な懸念事項ではありませんが、例外をキャッチすることは可能ですが、Windows がアプリケーションをクラッシュしたと認識し、Windows 7 でクラッシュ ダイアログを表示するのを止めることはできず、これは容認できません。

コードに関して、関連する事実は次のとおりです。

1. この例外は、アドインが WPF ホスト アプリケーションによってロードおよびアンロードされた場合にのみ発生します。アドインをアンロードする前に呼び出されるカスタム Dispose メソッドの一部として、アドイン内の WindowsFormsHost コントロールと Windows フォーム ベースのコントロールを破棄します。

2. アドインはアンロードの前に (上記の破棄プロセスの一部として) ディスパッチャをシャットダウンしています。これは、MSDN のドキュメントとブログの投稿に記載されていたものであり、この問題を解決するために必要でしたが、この場合は発生しませんでした。

3. 一部のレポートには Windows フォーム ベースのコントロールが必要であり、変換するレポート ファイルが多すぎ、適切な WPF バージョンがなく、変更する時間がないため、Windows フォーム ベースのコントロールを使用する選択肢はありません。

私はコードのサンプルを提供することができないので、私が見逃したものがある場合に備えて、そのようなシナリオでの考えや以前の経験に手を差し伸べています.