8

VS 2005 から 2008 への移行のメリットを宣伝する投稿をいくつか読みました。ただし、実際に移行を行う際のさまざまな落とし穴について知りたいです。移行しようとしていますが、途中で突然発見するのではなく、どのようなスピード バンプを予測して計画するかを知りたいと思います。プロセスができるだけ簡単になるように、これに関する有益なガイダンスは大歓迎です。

ああ、私たちは主に C++ 開発会社であり、いくつかの中程度のサイズの製品と小さな補助ツールがたくさんあります。すべてのビルドが容易に自動化されるように、すべてに外部メイクファイルを使用します。この種の開発操作を移行するときに何を期待するかについての具体的な洞察が最も役立ちます。

助けてくれてありがとう!

4

8 に答える 8

2

Visual Studio プラグインを使用すると、互換性の問題が発生する可能性があります。最初に切り替えたとき、2008 をサポートする Resharper のバージョンはまだ出ていなかったため、当時は小さな問題でした。それ以外では、IDE 自体に問題はありませんでした。そうは言っても、私たちは C++ をあまり使っていないので、あなたの状況がどのように異なるかはわかりません。

考えてみれば、スイッチで発生した他の唯一の問題は、nant を使用した .Net 3.5 アプリのビルドに関するものでした。どのビルド ツールを使用しているか、またはマネージ コードを実行しているかどうかについては言及していないので、これが問題になるかどうかはわかりません。そうである場合、nant を 3.5 アプリで動作させるための回避策がネット上にいくつかあります。これには、nant の構成ファイルの微調整が含まれます。掲載を希望される場合はお知らせください。

于 2008-10-17T01:17:07.717 に答える
2

私の以前の会社のアップグレードの経験は次のとおりです。

  • 特にマルチスレッド化が激しく、デバッグが面倒なアプリがあったため、信頼性が向上しました。
  • VS2008 は大幅に高速であり、RAM の消費も少なくなっています (少なくとも 50 プロジェクトのソリューションでは)。
  • 一部の C++ コードは、NT システムでは実行できなくなりました。これは、古い editbin 実行可能ファイル (VS2003 など) を使用して、ポスト イベントの一部としてバイナリを変更することで解決できます。
  • VS2008 にアップグレードすると、プロジェクト ファイルも更新されます。そのため、2 つの IDE の間を行き来する必要がある場合 (たとえば、すべての開発者が移行したわけではない場合)、問題が発生する可能性があります。
于 2008-10-17T02:25:07.533 に答える
2

完全に信頼できるものではないことがわかりました。ほとんどの場合は問題ありませんが、私たちの何人かは、5 分ごとにクラッシュするように見える日がありました。率直に言って、それも少しバグがあるように感じます。SP1 で修正されていない、リソースに関する巡回バグがあります。

移行中に「リンク時のコード生成」が明らかに自動的にオンになり、IMO が遅すぎます。リンク時間が 30 秒から 7 分に短縮されたことは、飲み込むのが非常に困難でした。それを再びオフにしました...

プラス面としては、デバッグが大幅に高速化されます。これは、時間のかかるコードにバグがある場合に大きなプラスとなります。ただし、リリースのビルド速度については確信が持てません。

それでも、他の言語には素晴らしい機能がたくさんあるかもしれませんが、私が見る限り、Visual C++ チームはその間の 3 年間、それほど忙しくはないようです (または、残っているのは 2 つほどしかないのでしょうか?)。

于 2008-10-17T02:38:23.497 に答える
1

私が Visual Studio 2008 で経験した唯一の問題は、少し調整するまで非常に遅かったことです。デバッグ モードからの復帰に 8 ~ 10 秒程度の遅延が発生していました。これは非常に面倒でした。SP1 は、一部の IE 設定の変更と同様に役立ちました。

しかし、そうでなければ、私はそれに満足しています。

于 2008-10-17T01:09:59.603 に答える
0

先月、アップグレードが完了しました。速度の低下には気づいていませんが、最初からSP1を実行しています。SP1のベータ版(サービスパックのベータ版?!?!)をインストールするのを間違えたため、RTM SP1をインストールする前に、特別なツールをダウンロードして実行し、削除する必要がありましたが、影響はありません。最大の問題は、2008年にすべてのサードパーティライブラリを構築し、バッチプロセスを機能させて、お客様の1人のためにプロジェクトとソリューションを2005にバックコンバートすることでした。ライブラリについて-Microsoftは、パブリックインターフェイスにC ++がある場合、または内部でSTLを使用している場合は、新しいコンパイラで再構築する必要があると述べています。ブログにちょっとしたあらすじを書きました。

編集:これが私たちが使用したプロジェクトコンバーターです。バッチプロセス用にコマンドラインアプリに変換しましたが、かなりうまく機能します。

于 2008-10-17T01:34:44.607 に答える
0

変更に気付かずに遭遇した1つの落とし穴(私にも質問の投稿があります)インストーラーは異なる動作をする可能性があります。古いアップグレードは、アンインストールと再インストールでした。新しいものはインプレースアップグレードを行います。これは問題につながる可能性があります:

  1. バージョン情報をDLLに入れる必要があります-悪いことではありませんが、自動化されたステップではない可能性があります

  2. 箱から出して、サービスは自動アップグレードできません。ユーザーに古いものをアンインストールしてから新しいものをインストールするように強制する必要があります(TODO:質問投稿の引用をここに追加します)

于 2008-12-16T10:10:35.383 に答える
0

私は2つの問題に遭遇しただけです。

  1. RTMを使用して2008年に最初に移行したとき、いくつかのサードパーティのアドインは機能しませんでした。どれかは覚えていませんが、現在使用しているアドインでこれに遭遇したことはありません。

  2. TeamEditionまたはTeamSuiteを使用している場合、2005TFSAPIを参照しているために機能しないサードパーティのチェックインポリシーがいくつかあります。かなり単純なので、コードを持っているもの(CodePlexからプルダウンされたものなど)の適切な参照を再コンパイルするか、ポリシーを書き直すことで、これを回避することができました。

私が述べたように、私たちが抱えていた唯一の問題はサードパーティの拡張性に関するものであり、数か月間は問題がありませんでした。

于 2008-12-16T10:29:06.470 に答える
0

信頼性が大幅に向上しました。毎日の機能セットは変更されていません (本来あるべき姿です)。

于 2008-11-02T00:46:47.493 に答える