1

次の状況で、業界標準や最終的にどのように取り組んでいるのかについての提案を知りたいと思います。

さまざまな日付で公開される複数のSilverlightプロジェクトを作成しています。これらのプロジェクトはすべて、varios共有コード（一般的なdll）を使用しています。これらの共有コードは、クライアント側またはサーバー側で使用されます。私の質問は、共有コードが変更された場合、影響を受けるすべてのプロジェクトを再コンパイルし、共有コンポーネントを使用する実際のコードに変更を加えた場合にのみリリースまたは再コンパイルしますか？

今のところ、クライアント側では、各Silverlightプロジェクトにアセンブリ参照フォルダーを作成し、そこに最新の必要なdllを配置します。これにより、XAP自体に必要なすべてのファイルが含まれ、他のプロジェクトと競合することはなく、正常に動作します。このアプローチでは、一般的なdllが変更されたという理由だけで、他のクライアント側のコードを再構築しません。複数のプロジェクトに共通のdll変更が必要な場合は、影響を受けるすべてのプロジェクトに最新のコピーをドロップし、それらをビルドして配布します。

一方、サーバー側（EFを使用するドメインサービス）では、すべてのサービスコードがWebサイトのbinフォルダーの下にあります。したがって、共通dllに変更を加える場合は、現在のプロジェクトが機能するように最新の共通dllを公開するだけでなく、他のすべてのサービスを再コンパイルして新しいdllを使用する必要があります。

ご意見・ご提案をお聞かせください。ありがとう

4

2 に答える 2

0

可能なアプローチは2つあります。

  • ソリューションに共通コードを追加し、プロジェクト参照を作成します
  • ビルドプロセスを取得してフォルダーにビルドし、そこから参照します

私は最初のオプションを好みます。私は常に最新のコードを使用してビルドとデバッグを行い、古い参照について心配する必要はありません。私は過去に2番目のアプローチを使用しましたが、これは面倒で、存在しないバグをデバッグした後、チームの時間を無駄にする可能性があります（古いバージョンを参照）。実際、Visual Studioが利用可能になったときに、それ以降のバージョンを取得できないことがあったことを覚えています。

于 2011-04-01T15:48:08.907 に答える
0

Silverlight プロジェクトのもう 1 つの方法は、 MEF を使用して、共通ライブラリを含むXAP ファイルを動的にダウンロードすることです。その後、共通ライブラリが変更された場合は、更新された "CommonLibraries.xap" を発行できます。Silverlight クライアントは、Silverlight アプリケーションの残りの部分とは無関係に更新を取得できます。

これらの共通ライブラリを使用する他のプロジェクトでも同じアプローチに従うことができます。アプリケーションは、共通ライブラリを動的にロードして、共通ライブラリを個別に更新できるようにすることができます。

可能であれば、WCF サービスを介して "共通ライブラリ" コードを使用することを検討してください。

于 2011-04-01T16:27:24.393 に答える