2

dotnet プロジェクトのセットアップ方法の例はたくさんありますが、私たちの状況に合うものはありませんでした。

複数のアプリケーションと複数の依存関係を持つ 1 つのソリューションがあります。私たちは現在 SourceSafe を使用しており、Subversion に移行する予定ですが、ソースを正しい方法で編成するのが難しいと感じています。

  • 解決例

    • アプリ1
    • アプリ2
    • ビジネスオブジェクト
    • データアクセス
    • カスタムコントロール

  • 依存関係

    • BizObjects->DataAccess
    • App1->CustomControls
    • App1->BizObjects
    • App1->DataAccess
    • App2->CustomControls
    • App2->BizObjects

また、オペレーターが作業しているワークロードに応じて (データベースからのコピーを介して) 展開する構成管理システムもあります。バージョンでアプリケーションの「リリース」をマークし、そのリリースに複数のファイル依存関係を追加します。現在実施しているソリューションは、古い (Windows 3.1 で開発された) ソリューションを .NET ファイル/依存関係構造で動作させるための応急処置であることに注意してください。

App1 の場合、App1.exe、BizObjects.dll、DataAccess.dll、および CustomControls.dll があります。BizObjects が DataAccess を参照しているため、App2 にも同じ一連の依存関係がありますが、これは手動で定義されています。依存関係ツリーを識別するためのシステムが整っていません。

「リリース」の各依存関係は、ファイルとバージョン ID です。また、同じアプリケーションに、ワークロードごとに異なるバージョンの各ファイルを含めることができます。

  1. 世界のどこで私たちは間違っていたのでしょうか? 私たちは間違っていましたか？
  2. 展開要件に対応するために、svn ソース ツリーをどのように構築できますか?
    • また
  3. セットアップに適した展開戦略をより適切にサポートするために、コードを再構築するにはどうすればよいでしょうか?

比較的単純な問題 (と思われる) に対して、古くて過度に設計されたソリューションがあります。誰かが私/私たちを正しい方向に導くことができますか?

編集:私はこの質問を読み、コードが通過しなければならない同じ開発/テスト/製品領域もあることに気付きました。

4

1 に答える 1

-1

ソースコード管理システムで構成管理を行おうとしているようです。

Subversion は、実行可能ファイル (バイナリ) と実行時の依存関係ではなく、ソース コード (ascii ファイル) とビルドの依存関係のためであるため、正しい選択ではない可能性があります。

私の推測では、本当にインストーラーが必要です: http://en.wikipedia.org/wiki/List_of_installation_software

あるいは、ネットワーク ドライブから正しい構成を起動するための単なるスクリプトかもしれません。

于 2008-09-03T03:11:23.073 に答える