あるVB.net2003のプロジェクトを改修することになったのですが、事情によりそのプログラムを作成したメンバーの人と話が出来ません。

そのプログラムは複数のソリューションから作られており、殆どのソリューションはビルドするとdllを作ります。
そして最終的にひとつのソリューションからそのdllが参照されて動くようになっているようなのです。

①何のためにこのようにソリューションを分ける必要があったのでしょう?推測でよいので教えてください。
②ビルドの際ソリューションを全部いちいち.netで開いてビルドを繰り返さなければなりません。うまい方法はないでしょうか?
③デバック方法がわかりません。ビルドはうまくいってもdllを作成するソリューションでデバック起動すると参照エラーがでてしまします。最終的にビルド後に共通のexeから呼ぶとうまくいくのですが・・・。

どれかひとつでもわかる人教えてください。
ちょっと質問が多いですが質問分けるのも面倒だし趣旨が逆にわかりにくくなりそうなので・・・。
そのかわり複数回答してくれた方にはポイントをそのぶんだけ増やします。

回答の条件
  • 1人5回まで
  • 登録:2006/08/17 20:21:25
  • 終了:2006/08/22 13:52:36

ベストアンサー

id:Kumappus No.1

くまっぷす回答回数3784ベストアンサー獲得回数1852006/08/17 20:38:32

ポイント60pt

1)全体がどういうプロジェクトなのか、開発体制がどうなっているのかなどがよくわからないのですが、

http://www.microsoft.com/japan/msdn/net/bda/tdlg_ch3.aspx

の、

複数ソリューション モデルは、パーティション分割した単一ソリューション モデルよりも以下の点で優れています。

* 各プロジェクトは単一のソリューションだけに含まれます。これは、プロジェクトをシステムに追加したり、システムから削除することが簡単であることを意味します。

* 論理的な境界に基づいてシステムを複数のソリューションに再分割できるので、プロジェクトの依存関係による影響を受けません。たとえば、ビジネス機能の分野に基づいた分割を選択する場合があります。

を一応狙ったのでは。つまりソリューションの中で閉じて開発ができるので、ソリューションごとに別の開発者に振りわけて完成するDLLのAPI仕様だけをやりとりするだけで中身の作りかたは自由にできると。

ただし、程度の悪いコピペプログラマーが名前の衝突を避けるためにほとんど同じ内容のプロジェクトをまるコピーして並べただけ、というケースも考えられなくはないですが。一人でやってたのなら後者の可能性もなくはないですね。

2)本質的には(名前とかがぶつかっていなければ)、ソースを配置し直してひとつのソリューションにまとめ直す、が正解です。あとは…そうですね、

http://dobon.net/vb/dotnet/vs/devenv.html

何か適当なスクリプト言語(JScriptでもVBScriptでもPerlでもRubyでも)でコマンドラインからビルドする手があります。

私のところではついでにテストプログラムも続けて実行させていました。

3)これはソリューションをまとめないと無理ではないかと思います。別ソリューションだとお互いの参照が、リンクしてまとめられない限りできないように思います(これは、ちょっと自信なし)。

id:matttsu

なるほど・・。ただ3は痛いですね。

やはりまとめ直すほうが良いのかな。

うまいまとめ方とかあれば別回答でよいので教えていただければうれしいです。

普通にコピペじゃむりですよね?

2006/08/17 20:48:12

コメントはまだありません

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません