AppCodeフォルダーのクラスのメソッドを使用したaspxページがありますdoSomething(int[] x)
。配列の代わりにIEnumerableを使用するように関数定義を変更しましたdoSomething(IEnumerable<int> x)
。次に、「Webサイトの更新を許可する」を使用してWebサイトをプリコンパイルし、新しいApp_Code.dllを公開しました。現在、プリコンパイルされたバージョンのページでは、実行時にサーバーエラーが発生します:「メソッドが見つかりません」。
ページ「App_Web_[page].aspx。[random].dll」用に生成されたDLLも公開すると、機能します。それで、関数の署名がコンパイルされたページに何らかの形で埋め込まれているように見えます…?これはなぜですか?既存のコードを変更するときにこの問題を回避する方法はありますか?
共通クラスのコードを変更するたびに、すべてのページDLLを更新するのは嫌です。
4 に答える
ページがコンパイルされると、すべてのメソッドシグネチャが調べられ、基本的にそれらがロックされます。呼び出されているメソッドのシグネチャを変更すると、再コンパイルされるまでページはそのメソッドを見つけることができなくなります。
たとえば、次のようなクラスがあるとします。
public class Dog {
public void Walk(Int32 distance) {
/// blah blah
}
}
そして、これをページコードビハインドで呼び出します。
protected void MyButtonClick(....) {
Dog d = new Dog();
d.Walk(3000);
}
これがコンパイルされると、ページはInt32署名を持つwalkメソッドを期待します。
ここで、Dogクラスのwalkメソッドを次のように変更するとします。
public void Walk(Int16 distance) {
// blah blah
}
(はい、愚かな変更ですが、それは問題を浮き彫りにします)。この時点で、ページはInt32パラメーターを受け取るWalkメソッドを見つけることができないため、必要に応じて爆発します。
必要と思われるアセンブリを1つだけデプロイするのは良いことのように思えるかもしれませんが、実際のところ、コードに変更がいくつも発生する可能性があるため、これは非常に悪い習慣です。
プロジェクト全体の一貫性を確保することをお勧めします。大規模なWebサイトでも、展開にそれほど時間はかかりません。
もちろん、Webサイトプロジェクトを使用すること自体は、とにかく悪い習慣だと思います。コンパイルされていないコードをサーバーにデプロイし(本当に悪い)、VSは、使用するアセンブリを明示的に指示した場合でも(通常は予期しない、決して良くない)、プロジェクト内の参照を更新するためにドライブを検索し、すべてのメインコードを共通のapp_codeフォルダーに配置します(制限)など。私はここに続けて行くことができます...
Webアプリケーションの場合は、サーバー側のコードを変更するたびに再コンパイルする必要があります。別のアセンブリにあるか、WebアプリのApp_Codeフォルダーにあるかは関係ありません。
再コンパイルせずにコードを変更できるのは、Webサイト(Webアプリケーションではない)のみです。
ページが公開され、binフォルダーのdllに出力されたため、再コンパイルする必要があります。このdllは、次のシグネチャを持つメソッドを探しています。
doSomething(int[])
そして、それはもうありません。公開するときは、毎回すべてを更新してください。
'updatable'フラグを使用すると、aspxコード(つまりマークアップ)を更新できると思いますが、コードビハインドファイルはコンパイルされています。
次の種類の変更により、実行時例外が発生する可能性があり
ます。メソッドのシグネチャまたはプロパティのタイプを変更する。影響を受けるメンバーがすでにコンパイルされたページによって参照されている場合、例外がスローされます。サイト全体を再コンパイルした場合、一部の署名の変更によってコンパイルエラーや実行時エラーが発生することはありません。たとえば、.aspxページのコードResponse.Write(ClassA.MethodA()は、MethodAがintまたはshortを返すかどうかに関係なく、正常にコンパイルおよび実行されます。ただし、.aspxページがすでにコンパイルされていて、MethodAの戻りタイプを変更した場合再コンパイルせずにintからshortに変更すると、コンパイルされたコードはint署名を想定しているため、ランタイム例外がスローされます。
http://msdn.microsoft.com/en-us/library/ms366723.aspx#sectionToggle5から