4

この質問と同じように聞こえる用語が含まれている多くの質問(および回答)をこのあたりで読みましたが、それらはすべて、.Netのさまざまなメジャーバージョンに対して構築することを目的としていました。残念ながら、私はもっと深刻な問題を抱えています。

これが物語です。お客様は、バージョン2.0の.Netフレームワークを使用しています。2.0だけで、サービスパックはまったくありません。私たちの開発者は、以前は.Net2.0SP1を使用していました。これは正常に機能しました。現在、私たちが取り組んでいる他のプロジェクトのために、開発者(私自身を含む)は.Net2.0SP2に更新されました。そして、これが問題の始まりです。どうやら、その無限の知恵の中で、MSはメジャーバージョン(たとえば、2.1)をインクリメントせずにフレームワークにAPIを変更/追加することを決定しました。したがって、2.0に対してビルドすると、2.0 SP2(インストールされている場合)に対してビルドされ、構成する方法がないようです。そのため、開発者は2.0をターゲットにしていると考えてコードを記述できますが、顧客のマシンでは機能しません。

特定のビルド(msbuildを使用して実行)がテストボックスで失敗し始めましたが、開発者のマシンでは正常に動作することに気付きました。明らかに、テストボックスはクライアントマシンと同じようにセットアップされており、古いフレームワークには一部のAPIがありません。これで、ビルドファームは新しいバージョンのCLR(sperviceパックと上位のメジャーリビジョンを含む)をインストールしてすべてのプロジェクトをテストするため、元の2.0にないAPIを使用するビルドは失敗しなくなります...これ互換性テストのひどいニュースです。

だから私の質問はこれです。(同じメジャーバージョンの)特定のCLRリビジョンに対して(msbuildを使用して)ビルドする方法。それができない場合、特定のプロジェクトがCLRの特定のリビジョンと互換性のない機能を使用しているときにVS2005がエラーをスローすることを確認するにはどうすればよいですか(レンチを歯車に投げ込むため、FxCopまたは同様の統合なし、基本的なVS2005機能のみ)?

上記の質問に肯定的な答えがない場合、私はすべて代替案を探しています。

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

4

2 に答える 2

1

新しいAPIを使用しない限り、SP2への更新による影響はないはずです。ビルドマシンで正確にどのような障害が発生しましたか?

ところで、マイナーリビジョンを変更せずに何も追加すべきではなかったことに同意します。しかし、それはVistaのためであり、彼らは頭を失いました。

私は推測する。

于 2009-07-15T22:41:43.733 に答える
1

3.5SP1でこの問題が発生しました。残念ながら、簡単な解決策はありません。唯一の解決策は、1)サービスパックからの変更が影響しないことを期待するか(影響する場合と影響しない場合がある)、または2)それぞれに適切なサービスパックのみがインストールされた個別のビルドマシンを作成することです。そこに構築します。

于 2009-07-15T22:44:26.520 に答える