人力検索はてな
モバイル版を表示しています。PC版はこちら
i-mobile

あるVB.net2003のプロジェクトを改修することになったのですが、事情によりそのプログラムを作成したメンバーの人と話が出来ません。
そのプログラムは複数のソリューションから作られており、殆どのソリューションはビルドするとdllを作ります。
そして最終的にひとつのソリューションからそのdllが参照されて動くようになっているようなのです。

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

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

●質問者: matttsu
●カテゴリ:コンピュータ
✍キーワード:.NET DLL exe VB.NET うまい
○ 状態 :終了
└ 回答数 : 1/1件

▽最新の回答へ

1 ● くまっぷす
●60ポイント ベストアンサー

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

◎質問者からの返答

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

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

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

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

関連質問


●質問をもっと探す●



0.人力検索はてなトップ
8.このページを友達に紹介
9.このページの先頭へ
対応機種一覧
お問い合わせ
ヘルプ/お知らせ
ログイン
無料ユーザー登録
はてなトップ