ソルーションを名前を変えて保存する手順。

Question

あるexpertシステムに使うDLLのサンプルexpertsample.dswがあり、これをダブルクリックすると、古いプロジェクトの形式から新しい形式（ｖｃ＋＋２００８用？）に変換して読み込まれます。次にビルドを行うと、サンプルのあったフォルダにreleaseフォルダ（この指定をした）とexpertsample.sln他が作られます。
やりたいことは
１．ビルドしたソルーションを、通常vc++2008でビルドしたときにソルーションファイル類がおかれるパス（\documentandsetting\usefolder\mydocuments\visualstadio2008\projects)に配置したい。フォルダのコピーでなく、名前を変えて保存などの手法でやりたいですが、手順がよくわかりません。

２．上記あるいは、上記で保存したソースを一部変更して、signプロジェクト名（ソルーション名）として、上記と同じフォルダ（projects）配下に作成したい。　１．の方法がよく見えないので、２．の手順も堂々巡りでよくわかりません。

わかりやすい手順のご教示をお願いします。現用のBCB６をはじめて使ったとき、似たような問題でつまづき教えてもらったことがあります。

 

Answer 1

１つのソリューションとそれに含まれるプロジェクト、ソースコード一式のコピー（今のコードを元に別のものを作るという意味ではフォークといえるか）といったことであれば、Visual Studio からは実行するものはありませんので、エクスプローラーでフォルダーをコピーすることになります。

// Visual Studio の名前をつけて保存系はその 1 ファイルしか対象になりません。
// ソースを一部だけ変更した違うものを別に作りたいのなら、エクスプローラーで
// フォルダーコピーするのが手っ取り早い方法です。

Answer 2

ご返事ありがとうございます。
１．
ただ１回の操作だけでなくとも、複数回の操作に分けてもできないでしょうか。例えが不適当かもしれませんが、BCB6では、まずソースファイルに名前を付けて別フォルダに保存のあと、プロジェクトに名前をつけて、これと同じ別フォルダに保存とすれば、すべてのプロジェクトとソース類一式が別ホルダに作成され、以降はその新しいプロジェクト名で呼び出すことができます。（この順序を逆ではうまくいない）
というようなことなのですが・・・・。
２．
Ａソルーション（プロジェクトもソースもオブジェクトの名前はＡ）のあるフォルダＡをまるごとフォルダＢにコピーしても、そのソルーションやソースの名前はＡのままだと思うのですが、それらすべてをＢに簡単に変更することができるでしょうか。
また、スタートページの最近使ったプロジェクトにＢででるでしょうか・

３．一般に、このような目的（少しソースを変えて別名のソルーションを作る）ではどうするのがよいのでしょうか。

 

Answer 3

あるいは、名前Ｂで新規ソルーションを作成し、ソースＡを読み込み修正してビルドのような手順でもよいのですが、なかなかうまく行きませんでした。多分ソルーションの各構成要素の働きなどを正確に理解していないのだと思うのですが。

Answer 4

ソリューションファイルにはどの場所のどのプロジェクトを参照するかの情報が、プロジェクトファイルにはどの場所のどのソースファイルを参照するかの情報が含まれています。
このため、ソリューションを別名保存しようが、プロジェクトを別名保存しようが、ソースコードの別名保存まで実施しないと同じソースコードを参照し続けます。
完全なコピーを Visual Studio 上で実現するためには、ソリューションエクスプローラーで１つずつ選択して頑張るしかないでしょうから、規模によっては現実的な選択ではないと思いますよ。

私がやるとしたら、ソリューションフォルダーごと丸ごと別のところにエクスプローラーでコピーして、ソリューション名だけ変えてしまうとかですかね。
（「一般的に」と言うほど、多く実施されていることなのだろうか？という疑問も感じますが…）

一度、sln ファイルとか、vcxproj ファイルとか、テキストエディタで見ると物理的な形がイメージしやすいのでは。

Answer 5

>私がやるとしたら、ソリューションフォルダーごと丸ごと別のところにエクスプローラーでコピーして、ソリューション名だけ変えてしまうとかですかね。

Ａｚｕｌｅａｎさんは、ふだん、そのようなことはされないと読めます。　すると新しいプログラムを作るとき、ベースとなるソースを参照したり、元のプログラムを修正して新しいバージョンを作るとかする際は、どのようにされるのですか。

イメージしているのは、それぞれ別のソルーションで管理することなのですが。それでソースの一部を変更したソルーションを簡単に作成できればと思うのです。

Answer 6

そのような場合、一般的にはバージョン管理システムを導入します。

「導入します」と言うと大げさですが、要はファイル操作の際に、エクスプローラーを使うかバージョン管理システムを使うかの違いなだけです。

Answer 7

いえ、バージョン管理システムを必要とするようなニーズではありません。

バージョン管理のようなシステムでは、体系的に以前の修正を復元管理するような仕組みとおもいますが、

小生がイメージしているのは、あくまで今あるソース（プログラム）をベースに別なプログラムを作りたいだけなのです。その管理をｖｃ＋＋expressで行う際に、ソースを直接管理するのではなく、ｖｃ＋＋から起動する際のソルーションとして管理したいだけなのです。IDEと言うからには、そのようなことを簡便に処理する仕組みが備わっているか、もしくは簡単な操作で実現できるはずと思っています。

sayuri（カット＆ペーストができずすみません）さんは、このような場合、VC++をどのようにお使いですか。

（この記入欄自体もコピーできないので不便）

Answer 8

Ａｚｕｌｅａｎさんは、ふだん、そのようなことはされないと読めます。

文面で雰囲気が出ていたかもしれませんが、多いか少ないかでいえば、少ないことです。

単純なクローンは、実験や試行錯誤レベルならよいのですが、たいていは後に問題を残すので…。
たとえば、クローンしたコードに不具合が見つかった場合、クローン元を含めてすべて直すとしてその追跡は可能なのか？という問題もあります。

すると新しいプログラムを作るとき、ベースとなるソースを参照したり、元のプログラムを修正して新しいバージョンを作るとかする際は、どのようにされるのですか。

小規模であってもバージョン管理システムの導入を検討します。
実際、最近個人的に作った Windows Phone のアプリケーションは数ファイルレベルながら、TFS に入れてラベルを貼っていますね。必要になったブランチを作るでしょうけど。
企業活動としてなら、バージョン管理システムは導入すべきだと思います。リリース時点のソースコードを得るとか、新しいバージョンとして分岐するとかかなり有用です。

なお、本当に小規模かつ、一時的な実験目的であれば、先にも書きましたが、丸ごとコピーしています。
これは「そう読めない」と言われても事実なので…。
あとは、派生品を作る際は、必要に応じてクラス単位で持ってくることはありますが、丸ごと流用はないですね。

-----

「IDE から簡単にできるはず」とお考えのようですが、私はそのような機能は存在しないという認識です。（手元の Ultimate にて触る限り）
仮にできたとしても、Express というエディション向けに提供されることはないだろうというのも私は思いますが。。。

TFS などは、クライアントとしての機能が IDE に統合されているので、そういう意味では IDE から分岐（ブランチ）などの操作は可能であるといえるので、「IDE というからには」という点に関してはある意味実現しているとはいえますね、期待に反するのかもしれませんが。

Answer 9

Azuleanさんがほとんど答えられていて私もそれに同意しています。そのうえで少しだけ補足。

Visual Studioはソリューションを最大の単位としてその配下にプロジェクトを持たせています。つまり、ソリューションをまたがって処理することは想定されていません。
それとは別に、ファイル構成を把握した上で他のプロジェクトからコードを流用したい場合、Visual Studioはファイルのコピーではなくリンクをサポートしています。（link.exeのことではありません。）
この場合、双方のプロジェクトでコード修正した場合に他方に影響を与えてしまいますので、あくまで利用者がファイル構成を把握していることが前提です。

結局、機能はありますがバージョン管理システムで管理するのが一般的な手法だと思いますよ。逆に質問ですが、sige2さんはバージョン管理システムをどの程度使いこなしているのでしょうか？

Answer 10

どうもやりたいことがなかなかご理解いただけないようです。単に自分用の実験的にプログラムを作っているだけで、バージョン管理システムのような本来の目的とする仕組みは必要としません。
あくまで、あるソースをもとに、別のプログラムを次から次へと作るだけです。失敗してもとに戻したいときはやりなおすだけです。
今必要なことは、あるソースから別のプログラムをつくるだけです。これを簡便に行うためのVC++で普通に行う方法についてお尋ねしているだけです。バージョン管理システムを使わなければ、この目的は面倒です（という風に聞こえます）というのは経験上理解できかねます。
ｖｃ＋＋のリンク機能がサポートされているそうですが（内容は未理解）、ソルーションのファイル構成を理解を必要とされるそうで、そのようであれば、VC++初心の内は使えないですね。初心者でも、あるソースをもとに別なプログラムを作るのは当たりまえだと思います。
いろんなレベルがある中で、この簡便な目的にどうするのが一番良策かとおたずねしました。

Answer 11

どうもやりたいことがなかなかご理解いただけないようです。単に自分用の実験的にプログラムを作っているだけで、バージョン管理システムのような本来の目的とする仕組みは必要としません。
（中略）
いろんなレベルがある中で、この簡便な目的にどうするのが一番良策かとおたずねしました。

細かいことを放置して、このスレッドにおいて私が言っていたこと書き直しつつ、一部補完すると以下になります。

• おすすめは、エクスプローラーでフォルダーを丸ごとコピーすることです。
  ただ、このままだと A.sln が２つ最近使ったプロジェクトとして出てきて紛らわしいので、A.sln を B.sln というようにエクスプローラーでリネームしてから開きます。
  （どうしても必要なときはこうしてます）
• Visual C++ の IDE からどうしてもやりたいなら、ソリューション、プロジェクト、ソースコード（cpp、h、rc などすべて）を個別に名前をつけて保存で実行してください。
  （コツとしては、ソリューション、次にプロジェクトというように範囲が広い順にやること）

Answer 12

今ＡホルダにあるプログラムＡ.cppやa.slnなどを丸ごと、Ｂフォルダにコピーしました。
Ｂフォルダにあるファイル名はもちろんa.*　のままです。
これらを、B.*にしたいのですが、手動でリネームしなければならないのでしょうか。
まず試しに　a.cppとa.slnだけ、b.cpp、b.slnとしてリネームしました。
ファイルー開くープロジェクト／ソルーションでb.sln　を開き、リビルドをしました。
するとa.cppが開けないエラーとなります。これはソルーションファイルB.slnの中身をBフォルダに適合するように変更していないから（つまりAフォルダにあったときの環境のままだから）当然でもあるようです。すべての関係を修正すればよいのでしょうが、それでは何のためにVC++のIDEを使っているのかわかりません。

ご提案のようなすべての関係する名前を手動で変更する方法は、とても採用できる方法とは言えないと思います。

（上記の投稿内容は、直近のご返事を見ずに書いたもので、結論は同じようなのでご了解ください）

Answer 13

ファイル－新規作成－既存コードからプロジェクトを作成から
既存コードファイルから新しいプロジェクトの作成ウィザードと下記のリンクからほぼ目的のことができることがわかりました。
少し実施すると所要のDLLオブジェクトができました。ただ、新規にプロジェクトおくフォルダを新規作成する選択肢はなくあらかじめ用意しなければならないのが少し残念でした。
このウイザードの存在は早くからわかっていましたが、その項目の理解ができず、下記リンクでようやく全貌がわかった次第です。

http://msdn.microsoft.com/ja-jp/library/b9cy3d6x.aspx
http://msdn.microsoft.com/ja-jp/library/6y1081yz.aspx

Answer 14

今ＡホルダにあるプログラムＡ.cppやa.slnなどを丸ごと、Ｂフォルダにコピーしました。
Ｂフォルダにあるファイル名はもちろんa.*　のままです。
これらを、B.*にしたいのですが、手動でリネームしなければならないのでしょうか。

そうなりますね。
それに対する回避としては、流用する可能性があるコードは exe 固有の名前を使わず、機能や役割を表す名前を採用するようにして、名前を変えないといけない必然性をなくすということになるかと思います。

現在の Visual Studio には、C++ のファイルの #include も含めてリネームを支援するリファクタ機能や、今のソリューション・プロジェクトを物理的にコピーする機能は存在しないと考えられます。機能に関する提案・リクエストに関してはフォーラムに書くのではなく、Connect サイト（うまく表示されないなら こちら ）に提案してください。あくまで、提案なので採用されないこともあり得ます点、ご留意ください。
ただ、次期 Visual Studio もすでに開発終盤なので、新機能が載ることは期待薄です。

Answer 15

そうなりますね。
それに対する回避としては、流用する可能性があるコードは exe 固有の名前を使わず、機能や役割を表す名前を採用するようにして、名前を変えないといけない必然性をなくすということになるかと思います。

残念ながら、そのようなプログラミングスタイルは数十年個人的なプログラムを行っている者にとって性にあいません。個々の関数機能でプログラミング環境を管理しているのではなく、あくまで、非常に多岐でバージョンが多数ある目的プログラムは、その目的プログラムごとに全体のソースで管理しています。共用できる関数は少ないですが、ある場合は、ソースレベルで単にインクルードファイル化しているだけです。わずかな機能差をプログラムで実験しているような感じです。

VC＋＋の機能拡張の提案などをするつもりはまったくありません。