[プロジェクト]-[プロパティ]-[実行可能ファイルの作成]でバージョン番号を設定できますが、それ以外の方法で設定が出来ないでしょうか?
ある共通のソースを利用して異なるEXEを作成していますが、共通ソースを修正した時に、上記情報の修正忘れで、同じバージョンのEXEで異なる動作をし、現場が混乱します。
出来れば、バージョン専用ファイルを作成し、そのファイルに設定されたものをバージョンと認識できないでしょうか?

> [プロジェクト]-[プロパティ]-[実行可能ファイルの作成]でバージョン番号を設定できますが、それ以外の方法で設定が出来ないでしょうか?

プロジェクト ファイル(*.vbp)の中に、MajorVer / MinorVer / RevisionVer という
エントリがありますので、それを編集してください。
その上で、/make パラメータで手動コンパイルするというのはどうでしょうか。

なお、手動コンパイルの方法については、「ファイル名を指定して実行」画面などから、
VB6.EXE を /? オプション付きで起動すると表示されます。

早速のご提示、ありがとうございます。
> プロジェクト ファイル(*.vbp)の中に、MajorVer / MinorVer / RevisionVer という
> エントリがありますので、それを編集してください。
現在も変更漏れが無いようにするため、一度にvbpファイルを修正するようにしていますが、あくまでこれは人の運用による管理であり、関係EXEが十数個わたるので漏れが出てしまいました。出来れば1つのファイル等を修正することで対応できないでしょうかね。

> その上で、/make パラメータで手動コンパイルするというのはどうでしょうか。
この方法はやっていませんでした。この方法とvbpファイル修正を考慮して、対応洩れしにくい方法が出来るかもしれませんね。一度考えて見ます。

相手はただのテキストファイルなので、バージョン管理情報を別ファイルに持ち、
それを元に vbp を修正するだけのツールを作るのは、さほど難しくは無いかと思いますよ。

これが標準 EXE だけではなく、ActiveX プロジェクトが含まれる場合は、
コンパイル順も重要になってくるので、依存性チェックが面倒になりますけど。


> 関係EXEが十数個わたるので漏れが出てしまいました。
ところで現在の開発は、
　(1) ある程度修正が進んだ後、それに対して新たなバージョン番号を割り振る。
　(2) 先に次のバージョン番号を決めて、それに向けて修正を行っていく。
のどちらの開発パターンでしょうか?

後者であれば、バージョンを決めた段階で vbp を更新してしまい、使用中のソース管理ソフト
(Subversion, WinCVS, Visual SourceSafe, Team Foundation Server 等)に、その vbp を
早々にチェックインする運用にするというのは如何でしょう。そうすれば、
管理ソフトによっては、修正漏れを vbp のチェックイン履歴から追跡できかも知れません。

親身なご提案をありがとうございます。
> 　(1) ある程度修正が進んだ後、それに対して新たなバージョン番号を割り振る。
> 　(2) 先に次のバージョン番号を決めて、それに向けて修正を行っていく。
前者を行っております。
当方不在時に上司の意向等で急に途中の状態で客先に提示されたりするので、適当な区切りでバージョンを決めざるを得ず、後者は難しいためです。

> ソース管理ソフト
も検討しましたが、スキルを得る苦労と開発規模を考えるとそこまでする・・・躊躇します。

ご指摘いただいたようにVBPがテキストファイルであるので、当方の開発業務に合うようにPGMを組むのが、結局使いやすくて確実だと思います。

ありがとうございました。

> 当方の開発業務に合うようにPGMを組むのが、結局使いやすくて確実だと思います。
そう思います。
今、ソース管理ソフトを使っていないなら、急に導入しても混乱を招きかねませんしね。


--- 以下雑記 ---

> > ソース管理ソフト
> も検討しましたが、スキルを得る苦労と開発規模を考えるとそこまでする・・・躊躇します。

今回の利用は見合わせるにしても、今後もバージョン管理が必要であれば、
検討しておくのも悪くないとと思いますよ。
(仕事だと、使いたいのに使わせてもらえない現場もありますが)

開発規模に関わらず、一人で開発する場合や、個人で使われる方もいらっしゃいますし。

# まぁ、Visual Studio 6.0 のインストール時に、Visual SourceSafe 6 が一緒に入るので
# 単にそのまま使っているだけという場合が多いようですが。(私の身の回りでは)


その一方で、導入に躊躇するユーザーが少なくない事も事実ですけれどね…。

VSS だと、中身が JET エンジンなので、DB破損が怖いとして NG と判断されたりとか。
TFS だと、オーバースペック or 予算オーバーという状況に陥ってしまったりとか。
SubVersion は利用者が多いけど、純正 MS 製品じゃないと許可が下りない現場とか。
そもそも、ソース管理をやった事が無いので、どういう代物かわからないとか。
便利なのは分かっているけど、下手に提案して管理者に任命されるのが嫌だったりとか。
実際に使ってみたけど、トラブルシュートしきれなくて諦めてしまったりとか。

> VSS だと、中身が JET エンジンなので、DB破損が怖いとして NG と判断されたりとか。
> TFS だと、オーバースペック or 予算オーバーという状況に陥ってしまったりとか。
> SubVersion は利用者が多いけど、純正 MS 製品じゃないと許可が下りない現場とか。
> そもそも、ソース管理をやった事が無いので、どういう代物かわからないとか。
> 便利なのは分かっているけど、下手に提案して管理者に任命されるのが嫌だったりとか。
> 実際に使ってみたけど、トラブルシュートしきれなくて諦めてしまったりとか。

JETエンジンに関してはさほど感じていませんが、その他は全くその通りです。
それぞれの文頭に、『頭の固い上司』『プログラムを知らないSE』『めんどくさがり屋の部下』等の説明を入れると、もっと的確なのでしょうが・・・
どこも同じ悩みがあるのでしょうね。
管理PGMに早速かかってみます。
ありがとうございました。