2011-07-27 7 views

答えて

1

私はテストを行いましたが、csc.exe 3.5を使用するコンパイラ要素を削除してweb.configを変更する必要がありました。私はすべてのファイルをあらかじめコンパイルして送信しているので、問題はありませんでした。

1

ここでの答えは、プロジェクトの依存関係がどのようなものかによって異なります。 ASP.NET 3.5は本当に存在しません - すべての集中的な目的のために、Visual Studioが統合するのに役立ついくつかの新しい拡張機能を備えたASP.NET 2.0があります。それはスタンドアロンのフレームワークではありません。

あなたがLINQまたはAJAXを使用していない場合は、自分のサイトがうまく配置されると思います。 LINQ/AJAXを使用している場合、Web.configで多くの手動アセンブリエントリを実行している可能性があります。

+0

しかし、あなたが失うものは、コードのコンパイル時検証です。なぜあなたは2.0で再コンパイルできないのですか? –

+0

@Cat - 私は彼がコンパイル時の検証を失っているとは思わない。彼は自分のサイトをプリコンパイルしようとしています。彼は、オンデマンドコンパイルを可能にすることでパフォーマンスの最適化を除いてすべての利点を得ます。デプロイするプロセッサアーキテクチャがデベロッパーボックスと異なる場合にのみ有益です。 – Brian

+0

それは3.5の機能を受け入れ、それは目的地では利用できないかもしれない。 –

-1

いいえ動作しません。サーバー自体に適切な.NETフレームワークをインストールする必要があります。

あなたは本当に別の答えを期待していましたか?

+1

これは正しいとは思わない。これは2.0のウェブサイトを1.1のボックスに展開するのとは異なります。これは、第三者の製品がインストールされていない別のマシンにサードパーティのリファレンスを持つ2.0のWebサイトを展開する場合に似ています...必要なDLLを含めると、それでも実行する必要があります... – Brian

1

これまでの説明のとおり、 いくつかのものはおそらく動作しますが、いくつかは動作しません。

GACに.NET 2.0アセンブリがあり、3.5アセンブリをbinフォルダに配置すると、アプリケーションはデフォルトでGACアセンブリ(2.0)を使用します。したがって、アプリケーションが正しく動作するかどうかは決して確認できません。

サーバーを再起動しなくても3.5フレームワークをインストールできます。したがって、すべての動作をさせるためにiisresetを1つ停止するなど、ダウンタイムを恐れる必要はありませんが、これまでこれを行う必要はありませんでした。

関連する問題