VC++2008から2010への移行に関して

Question

どうもお久しぶりです。

VC++2008からVC++2010用へ移行する際に、いくらか気になった事がありました。

まず、これらは一つのPCで問題なく共存できるという事で良いですか？

.vcprojやソース・ヘッダやマニフェストファイルやアイコンなどが詰まったプロジェクト用フォルダと.slnのソリューションファイル

のみのコピーをとり

VC++2010用へ「バックアップをとる」を選択して変換した際

・UpgradeLog.XML

・プロジェクト名.sln.old

・_UpgradeReport_Files（フォルダ）

├UpgradeReport.css

├UpgradeReport.xslt

├UpgradeReport.xslt

└UpgradeReport_Plus.gif

といったものが作成されました。

これらは、みたところ消しても動作するようなのですが、これらのファイルはバックアップ（？）のたぐいとおもうので、これらを使うとプロジェクトの設定をVC++2008用に復元できるのでしょうか？

また、もし復元する必要がなければ消しても全く問題ない、ということでしょうか？

また、通常のインテリセンスは.ncbから.sdfファイルになり

外部依存関係のインテリセンス（？）か何かが.ipchになった、ってことですよね？

また、それだけでは不安があったので、プロジェクト用フォルダの中身の変更点も探るように、プログラムを書いて全ファイルのバイナリの照合を行ってみたのですが

既存のファイル（700超全て）にはバイナリレベルで１ビットたりとも変更はなく

新たに以下のファイルが生成されていました。

プロジェクト名.vcxproj.user
プロジェクト名.vcxproj.filters
プロジェクト名.vcxproj

http://msdn.microsoft.com/ja-jp/library/ee862524.aspx

に書いてあるように

2010では.vcprojではなく.vcxprojを使うようになったということなのですが

.vcprojも１ビットも変わらず残っていました。

これもまた、削除しても支障はないものなのでしょうか？（「バックアップをとらない方」選択しても残ってたような気がしますが）

そして少なくとも上記の結果のように

ソースなどに関しては変換時には全く変更されない、という事でOKでしょうか？

Answer 1

大半のことはドキュメントで書かれていないことなので、挙動からの推測しか答えることができないものだと思われますが、それでよいのでしょうか？
「全く問題ない、ということでしょうか？」という質問に対して、「たぶん○○だと思う」という私見・推測を述べることができたとしても、それは保障ではないので、それを聞いて実際に違った結果、損害を被ったとしてもあなたの責任です。

という前置きをした上で、私見です。

• VC2008 と VC2010 の同居は可能です。
• UpgradeReport.*、UpgradeLog.xml は名前の通り、アップグレード時の結果を書いたものに過ぎないので、バックアップでも何でもないので、用が済めば消してよいものです。
• *.sln.old は名前の通り、古いソリューションファイルのバックアップです。
  なお、ソリューションファイルにはプロジェクトの設定は含まれていないので認識をただしておいてください。
• SDF とか IPCH はこの辺で出てきてますね。
• vcxproj に移行されるはずなので、vcproj は消してもよかった…はず。
• ソースコードは変わらないはず。

---

質問スレッドで解決した場合は、解決の参考になった投稿に対して「回答としてマーク」のボタンを押すことで、同じ問題に遭遇した別のユーザが役立つ投稿を見つけやすくなります。

Answer 2

ご回答ありがとうございます♪

＞挙動からの推測しか答えることができないものだと思われますが、それでよいのでしょうか？

それでよいです。最悪問題が発生してもソースコードさえ生きてれば、プログラムの機能を復元する手段は確実に存在します。また、「この調子で将来ファイルが増えてった時に、いらないものが大量にごちゃごちゃに混在する」状態になるのを懸念してるという意味なので、「おそらくは不要なファイル」を2008→2010にした時に確実にすぐ消さないといけないというものではありません。

＞VC2008 と VC2010 の同居は可能です。

ですよね？とりあえずVC++11まではC++/CLIは2008で、ネイティブコードは2010でやろうかなと考えています。

＞UpgradeReport.*、UpgradeLog.xml は名前の通り～

なるほど、確かにバックアップとらない方でもこれらは作成されました。

＞*.sln.old は名前の通り、古いソリューションファイルのバックアップです。～

あ～

こっちは正確にはソリューション名.sln.oldでしたかね

slnやsln.oldもテキスト形式で

Format Version とかプロジェクトの相対（？）パスとか

GlobalSectionなんちゃらとかが書かれてるだけで、確かにプロジェクトの個別設定に関してはノータッチっぽいですね。

ちなみに昔のバージョンに戻すとかっていうのは一括でやる手段は用意されてない、でしょうか？（…つまり必要事項調べて手作業？）

＞SDF とか IPCH

はい、日本語でしたが、そんな感じの文章を見た気がします。

＞vcxproj に移行されるはずなので、vcproj は消してもよかった…はず。

やっぱ、そういう判断になりますよね～。

＞ソースコードは変わらないはず。

ご丁寧にありがとうございます。

まぁ、考えてみれば

前述の通り今回確認のために独自のバイナリチェッカー作ったので

今後のバージョンアップで、もし万が一ソースコードが変化する場合が出たとしても、簡単にチェックできそうなので問題ないですし

100％かどうかは分かりませんが、実際変わってないという結果も確認したので、ひとまず不安要因はなさそうですね。

その他、ここまでに出ていない事で、「特に」注意すべきこととかってありましたでしょうか？

特にないですかね。

Answer 3

それでよいです。最悪問題が発生してもソースコードさえ生きてれば、プログラムの機能を復元する手段は確実に存在します。また、「この調子で将来ファイルが増えてった時に、いらないものが大量にごちゃごちゃに混在する」状態になるのを懸念してるという意味なので、（おそらくは）不要なファイルを2008→2010にした時に確実にすぐ消さないといけないというものではありません。

個人的には TFS など、ソースコードのバージョン管理システムを使った方がよりベターだと思います。
Visual Studio と連携して使えるバージョン管理システムであれば、一時ファイルは登録されませんし、チェックインした履歴は残っているのである程度さかのぼれますので。

ちなみに昔のバージョンに戻すとかっていうのは一括でやる手段は用意されてない、でしょうか？（…つまり必要事項調べて手作業？

少なくとも標準にはないでしょう。
通常は一方向ですし、バージョン管理システムがあったりして需要が低いと思われます。また、販売面でも逆方向をサポートするのは消極的になりそうです。

前述の通り今回確認のために独自のバイナリチェッカー作ったので

WinMerge というツールを使えば、ディレクトリ単位で比較できますね。
テキストなら DIFF を見れますし、バイナリでも差分があることを検出できます。

---

質問スレッドで解決した場合は、解決の参考になった投稿に対して「回答としてマーク」のボタンを押すことで、同じ問題に遭遇した別のユーザが役立つ投稿を見つけやすくなります。

Answer 4

どうもありがとうございます♪

個人的には TFS など、ソースコードのバージョン管理システムを使った方がよりベターだと思います。
Visual Studio と連携して使えるバージョン管理システムであれば、一時ファイルは登録されませんし、チェックインした履歴は残っているのである程度さかのぼれますので。

そんなものがあったんですね。

しかし、うぬぅ

調べてみるとHDDの空き容量的に厳しそうなので

現状では「将来的に」使う可能性あり、という判断にして置きます。

あんまりそこに考えがいってなかったので、そういえば、という話ですが

状況的に、プログラミング以外でもいろんなファイルを

大量に作ったり更新することがよくあるので、それらのファイルについてもバージョン管理システムというのは調べておく価値がありそうですね。

（流石に自分のつくったファイル形式以外のバージョン管理システムともなると、ブラックボックスになってると厳しいですし、高機能のものは自作している時間はなかなかとれないと思うので（といいつつ、自作とか、仕様が分かってるファイル形式のバージョン管理プログラムはちょくちょく書いてたりしてましたがｗ））

WinMerge というツールを使えば、ディレクトリ単位で比較できますね。
テキストなら DIFF を見れますし、バイナリでも差分があることを検出できます。

試してみました。

自分で作ったやつは

以前作ったファイル操作関連のプログラムをちょこっといじるだけだったので、１～２時間程度で作った、実行ファイルサイズ34KB程度のものでしたが

「今回の目的」に限定すると能力にほぼ差異はないようです。（ディレクトリ単位での比較も、どちらでやっても一瞬。・・・一応700越えぐらいになると流石に自作の方がだいぶ速いですが。）

「何か思いついたらまた自分で好きな処理を自由に書き足せる」「自分が作っている以上処理が丸見えなので、勘違いの恐れがない」「デフォルト設定とかも簡単に把握・変更可能」というメリットが

自作プログラムの場合ありますが、WinMergeも使ってるディスク容量は１０MB以内と、かなり低めなので、とりあえずこのまま残しといてまたなんか使う事があったら使うかも、って感じですね。