C++ コードで .NET CLR をターゲットにするレガシー (2003) 非推奨 (vs2005/vs2008) マネージ C++ (MC++) 構文を Microsoft が (コンパイルのように) 継続的にサポートする予定があるかどうか、誰でも (自信を持って) 知っていますか?
Microsoft は、VS2005 C++ コンパイラ (Orcas) で /clr:oldSyntax を公式に廃止しました。ありがたいことに、VS2008 C++ コンパイラはまだ /clr:oldSyntax スイッチをサポートしていました。
しかし、VS2010 の C++ コンパイラはまだサポートしていますか? それとも、VS2010 のリリースにより、最終的に /clr:oldSyntax との下位互換性が失われるのでしょうか?
プロジェクト計画のスケジューリングのために VS2010 がリリースされる前に知っておく必要がありますが、MSDN サイトまたは MVP サイトで公式の言葉を見つけることができませんか?
MSDNまたはMVPで情報が見つからない場合は、ここで直接Microsoftに問い合わせることをお勧めします（C ++のものだと思います）。私はマイクロソフトでは働いていませんが、別の（非常に）大規模な組織で働いており、開発者は公開フォーラムを非常に注意深く監視しています。そのサイトを見ているMS開発者はかなりいるのではないかと思います。
ただし、リスク管理と不測の事態なしにプロジェクト計画を行っている場合は、それを正しく行っていません。
サポートされない可能性を考慮して、2つのことのいずれかを実行する必要があります。
私の経験からすると、通常は最初の方が良いです。なぜなら、それを行う必要がなく、スケジュールが遅れている場合は、そのアイテムをドロップするだけで追いつくことができるからです。場合によっては、とにかくそれをドロップして、より早く納品することができます。これは、年次業績評価のために自分の見栄えを良くするためです:-)
しかし、それを許可せずに必要だと思ったとしても、リスクは問題に変化し、より多くの時間が必要な理由を説明するために上級管理職に行くことができます。リスクログで明確にされたので、あなたはカバーされます-それからあなたにもっと時間を与えるか、MSVCのバックレベルを使い続けるかは彼らの決定になります。
あなたがそれをする必要がないならば、あなたはおそらくそれを考慮すべきであるということを覚えておいてください（スケジュールのずれはありません）。マイクロソフトは笑いのためにそれらを非難しませんでした、それらはある時点で消えるでしょう。YAGNIは、差し迫っていない限り心配する必要はないと提案していますが、準備のために何らかの作業を行うのが賢明です。
これにより、Microsoftが最終的に機能を削除したときに、ぎりぎりのマッドラッシュを回避できます。
さて、あなたはCTPビットをチェックアウトすることができます。これは最終的なものを保証するものではありませんが、それは良い考えです。疑わしいことに、この時点でコンパイラに大きな変更が加えられるでしょう。