2

問題: クラス B はクラス A のサブクラスです。RIA サービスはオブジェクト B のリストを返します。クラス A と B はどちらもサーバー側で必ず定義されます。それらは正常にシリアル化され、プライマリ クライアント プロジェクトで使用できます。

他に 2 つのライブラリがあり、クライアント ライブラリとして編成されています。1 つはカスタム コントロール用で、もう 1 つはカスタム コントロールと実際のクライアント プロジェクトの間で共有されるクラス用です。

クラス ライブラリ クライアント側からクラス A にアクセスできるようにする必要があります (カスタム コントロールがアクセスできるようにするため)。これどうやってするの？

私はこれをやった：

http://msdn.microsoft.com/en-us/library/ee707369%28v=vs.91%29.aspx

ただし、*.shared.cs 規則では、実際のクライアント ライブラリ以外のライブラリはクラス A にアクセスできません。プロジェクトがクライアント バージョンを更新しないため、クラス ファイルが変更されるたびに両方のクラス ファイルを更新する必要があり、これは容認できません。

編集：数回再試行した後、リンクとして追加するとうまくいきました。

4

1 に答える 1

1

Visual Studio (少なくとも 2010 年 — 機能が追加された正確な時期は不明) では、既存の項目を「リンク」としてプロジェクトに追加できます。つまり、ソース ファイルはプロジェクト間で共有されます。ソース ファイルのバージョンは 1 つだけ存在します。

  1. プロジェクトを右クリックします。
  2. [追加..既存のアイテム] をクリックします。
  3. 選択したソース ファイルを見つけて選択します。
  4. 「追加」ボタンはドロップダウンです。ボタンのドロップダウン アイコンをクリックします。
  5. 「リンクとして追加」をクリックします。

簡単！

これで、共有ソース ファイルへの変更が両方の場所に反映されます。もちろん、欠点は、共有ソース ファイルへの変更が、開発者が認識しているよりも広範な影響を与える可能性があることを開発者が把握できないことです。

もう 1 つのオプションはhard link、2 つのファイル名が同じファイル (Unix 用語では「i ノード」) を参照するように作成することです。コマンド ラインで、魔法の呪文を唱えるだけです。

fsutil hardlink create <new-filename> <existing-filename>

何かのようなもの：

fsutil hardlink create c:\foo\bar\some-project\bazbat.cs c:\foo\bar\another-project\bazbat.cs

制限は、両方の名前が同じボリューム上にある必要があるということです。

もちろん、これはソース管理システムを混乱させる可能性があります。ファイルシステムが必ずしもツリー構造であるとは限らず、同じファイルが複数のディレクトリに存在する可能性を TFS が考慮していないことは間違いありません。

ハードリンクされたファイルは、任意の順序で削除できます。最後のリンクが削除されると、ファイルは存在しなくなります。

もちろん、3 番目のオプションであり、おそらく「ベスト プラクティス」です。この用語は嫌いです。— クライアントとサーバーの両方に展開される独立したアセンブリにシャード クラスを分解することです。ビルド後に浮遊するアセンブリの数を制限したい場合は、アセンブリilmergeをマージするために使用できます。

考えてみれば、必要に応じて (または起動時にも) 読み込まれる埋め込みリソースとして共有アセンブリを埋め込むことができない理由もありません。これは、 を使用するよりもきれいかもしれませんilmerge。その方法は次のとおりです。

http://blogs.msdn.com/b/microsoft_press/archive/2010/02/03/jeffrey-richter-excerpt-2-from-clr-via-c-third-edition.aspx

于 2012-08-10T16:29:29.187 に答える