ApplicationHost.CreateApplicationHost
メソッドを介してASP.NETランタイムをホストしています。アプリケーションの実行中にweb.config
を変更すると、多くの最初のチャンスThreadAbortException
sがスローされます。これは、アプリケーションがクラッシュする直前です。これは、ランタイムが構成への変更を検出し、再起動する必要があるためと考えています。
これは実際にサポートされているシナリオではないので、自動再読み込みをオフに切り替えられるようにしたいのですが。
誰でもこれを行う方法を知っていますか?
この動作を無効にする方法がないことを私が認識している限り、webconfigを変更すると、アプリケーションが強制的に再起動されます。
更新:実際に可能です。 この回答で説明されているように、十分に文書化された多数のメソッドがあります *
元の答え:
他の参照用に同様の質問 ここ があります。役立つと思われる追加情報を見つけました。
構成を変更するとアプリケーションドメインが再起動する
Web.configファイルの構成設定を間接的に変更すると、アプリケーションドメインが再起動します。この動作は仕様によるものです。オプションで、configSource属性を使用して、変更が行われたときに再起動を引き起こさない外部構成ファイルを参照できます。詳細については、 セクション要素によって継承される一般的な属性のconfigSourceを参照してください。
から このMSDN記事
* 免責事項:私は他の回答を書きましたが、通常は自己参照をしませんが、この投稿から8年後にここにリンクするのに十分関連性があると思います。それは本当にまったく異なります。解決策は、IISフロントエンド、および回避策はASP.NET 1.0以降に存在します。
実際、最初の2つの答えは正しくありません。このリサイクルが起こらないようにすることは、 is で可能であり、非常に簡単です。この機能は、少なくともIIS6から利用できます。
HKLM\SOFTWARE\Wow6432Node\Microsoft\ASP.NET\FCNMode
のDWORD
レジストリ設定を値1
に変更します。これにより、 all ファイル変更通知が無効になります。
場所を混同しないでください。この場合、Wow6432Node
はWebアプリケーションのビット数に影響を与えません。
.NET 4.5を使用している場合、 サイトごとのレベルでこれを無効にできるようになりました 、web.config
で次のように使用します。
<httpRuntime fcnMode="Disabled"/>
最後に、また(少なくとも)IIS6以降、アプリケーションプールのみの設定として DisallowRotationOnConfigChange
と呼ばれる設定があります(少なくとも、MSDNのテキストが言っているように思いますが、テストしていません)。これをtrue
に設定すると、アプリケーションプールの構成を変更しても、すぐにリサイクルされません。
この最後の設定は、アプリケーションプールの詳細設定からも設定できます。
ASP.NET 1.0または1.1を使用している(古い)Webサイトの場合、 確認されたバグがあります これにより、ファイルの変更時に迅速かつ繰り返しのリサイクルが発生する可能性があります。当時の回避策は、メインの質問の下で提案された MartinHN に似ていました。つまり、web.config
の次のようなものです。
<compilation
debug="false"
defaultLanguage="vb"
numRecompilesBeforeAppRestart="5000">
これはリサイクルを無効にするわけではありませんが、 5000 再コンパイルが行われた後にのみ無効になります。この数が役立つかどうかは、アプリケーションのサイズによって異なります。 Microsoftは、 recompilation が実際に何であるかを明確に述べていません。ただし、デフォルトは 15 です。
余談ですが: .NETまたはWindowsのバージョンに関係なく、アプリケーションが共有から実行され、負荷分散環境で使用されると、サイトは継続的にリサイクルします。 。これを解決する唯一の方法は、そのFNCMode
設定をレジストリに追加することでした(ただし、より詳細なオプションがあります)。
同じ行に沿ってさらに大きな問題が発生しました。AppDomainベースディレクトリのanyファイルまたはサブフォルダーを変更すると、ホスティング環境がシャットダウンします。同じAppDomainでWPF UIを実行しているため、これはアプリケーションにとってかなり大きな問題であり、ユーザーに邪魔されずに再起動することはできません。
アプリケーションのWebベースの部分に対して個別のAppDomainを実行する必要がないようにしたかったので、Reflectorを使用して掘り下げました。犯人は内部クラスFileChangesMonitor
であることがわかりました。
だから私は問題を解決するために恐ろしい恐ろしい反射ハックを書いた。同じ問題を抱えている他の人のための潜在的な解決策としてここに投稿すると思いました。ファイル/フォルダーの変更に対するシャットダウンを無効にするには、HttpInternals.StopFileMonitoring()
を呼び出すだけです。
internal static class HttpInternals
{
private static readonly FieldInfo s_TheRuntime = typeof(HttpRuntime).GetField("_theRuntime", BindingFlags.NonPublic | BindingFlags.Static);
private static readonly FieldInfo s_FileChangesMonitor = typeof(HttpRuntime).GetField("_fcm", BindingFlags.NonPublic | BindingFlags.Instance);
private static readonly MethodInfo s_FileChangesMonitorStop = s_FileChangesMonitor.FieldType.GetMethod("Stop", BindingFlags.NonPublic | BindingFlags.Instance);
private static object HttpRuntime
{
get
{
return s_TheRuntime.GetValue(null);
}
}
private static object FileChangesMonitor
{
get
{
return s_FileChangesMonitor.GetValue(HttpRuntime);
}
}
public static void StopFileMonitoring()
{
s_FileChangesMonitorStop.Invoke(FileChangesMonitor, null);
}
}
解決策は、次の要素をweb.configセクションに追加することです。
<httpRuntime
waitChangeNotification="315360000"
maxWaitChangeNotification="315360000"
/>
Jfburdetで述べたように、解決策はwaitChangeNotificationとmaxWaitChangeNotificationを使用することです。
そうは言っても、ASP.NETが混合モードで実行されている場合は、IIS 7で動作しないことを知っている必要があります。 http://forums.iis.net/t/ 1149344.aspx