Application_Startが起動しませんか？

私が作業しているASP.NET MVC（ベータ）アプリケーションがあり、何か間違っているのかApplication_Start、Global.asax.csのメソッドが実際に起動しても起動しないのかを理解するのに問題がありますアプリケーションをデバッグします。

私のApplication_Startメソッドの行にブレークポイントを設定し、アプリケーションをデバッグしようとすると、ブレークポイントがヒットするはずだと期待していますが、実際にはヒットしません。IISをリセットした後ではなく、再起動した後ではありません。何か不足していますか？このメソッドが呼び出されないのはなぜですか？

これがIISにある場合、デバッガーが接続する前にアプリを開始できます。もしそうなら、私はあなたが接続するのに十分な長さの睡眠をスレッドできるかどうかわかりません。

Visual Studioでは、デバッガーをプロセスに接続できます。これを行うには、[デバッグ] >> [プロセスにアタッチ]をクリックします。ブラウザに接続して、アプリケーションにアクセスします。安全のために、IISを再起動してサイトにアクセスしてください。これで問題が解決することを100％確信しているわけではありませんが、App_Startでスレッドスリープを開始するよりもはるかに優れています。

別のオプションは、アプリケーションの開始のデバッグを完了するまで、組み込みのWebサーバーで一時的にホストすることです。

注：組み込みの「Visual Studio Development Server」またはIIS Express を使用するのに最適な簡単な代替手段（たとえば、IISに対して開発していて、アプリが適切に機能するために必要な特定の設定があるため）は、IIS（IカスタムWebサーバー+ホストファイルエントリ+同じドメインへのIISバインディングを使用する）

1. デバッグセッションが起動するまで待ちます
2. 次に、空白をルートのweb.configに編集してファイルを保存します
3. ページを更新する（Ctrl + F5）

ブレークポイントにうまく到達し、自然なIIS生息地でデバッグを続行できます。すごい ！

以下は、どんな場合でも役立ちます（IIS、Cassiniなどを使用しているかどうかは関係ありません）。

1. Application_Startにブレークポイントを設定します
2. デバッグを開始します（おそらくブレークポイントはヒットしません）->ブラウザにページが表示されます
3. web.configを変更（例：空白行を入力）して保存します。
4. ブラウザでページをリロードします->ブレークポイントがヒットします！

なぜこれが機能するのですか？web.configが変更されると、Webサーバー（IIS、Cassiniなど）がリサイクルを行いますが、この場合（何らかの理由で）プロセスは同じままなので、デバッガー（Visual Studio ）。

ホストされているアプリであるIISのapplication_startのブレークポイントに問題があります。適切な回避策は、Debugger.Break（）;を使用することです。VSブレークポイントの代わりにコードで

私も同じ問題を抱えています。私は自分のソリューションで多くの名前変更を行いました。その後、2つの動作していないWebアプリケーションを取得し、他のいくつかのWebアプリケーションは正常でした。ルートが間違っているというエラーが発生しました。Application_Startメソッドにブレークポイントを設定してからIISを再起動しようとしたが、VSは実行を中断しなかった。実行可能なWebアプリケーションでは、休憩が機能していました。次に、「クリーンソリューション」と「リビルド」は、名前変更後に残ったアセンブリを削除しないことを思い出しました。そしてそれが解決策でした！binbuggy-web-applicationsのディレクトリを手動で削除したところ、Global.asax Inherits=""属性に新しいエラーがあり、古いdllが参照されていました。私はそれを新しいものに変えて、休憩が働き始めました。Global.asaxの名前変更中に更新されなかったと仮定します。

別のベンダーがビルドした後に引き継いだプロジェクトでも同じ問題がありました。問題は、Global.asax.csに以前のベンダーによって作成されたコマンドがいくつかあり、それが使用中であると思わせるかもしれませんが、実際には完全に無視されていたということです。Global.asaxはそれを継承していなかったため、.csファイルが存在する場合、このファイルが表示されないのは簡単です。実際に表示するには、Global.asaxを右クリックして[マークアップの表示]をクリックする必要があります。

Global.asax：

<%@ Application Language="C#" %>

次のように変更する必要があります：

<%@ Application Codebehind="Global.asax.cs" Inherits="ProjectNamespace.MvcApplication" Language="C#" %>

ここで、ProjectNamespaceはGlobal.asax.csクラスの名前空間です（通常はプロジェクトの名前）。

私たちの場合、ファイルには一連のインラインコードが含まれており、その一部は.csファイルからコピー貼り付けされていましたが、そうでないものもあります。インラインコードを.csファイルにダンプし、徐々に変更をマージして戻しました。

アプリプールのマネージパイプラインモードを「統合」ではなく「クラシック」に切り替えてみてください。これで問題は解決しました。理由を調べています...

（この回答の小道具はフローレスに属します（彼自身の回答に関する彼のコメントを参照してください）。もっと注目を集めるために、これを個別の回答として提供したかっただけです）

global.asaxがサブディレクトリの下にないことを確認してください。プロジェクトのルートレベルに配置する必要があります。

同様の問題があり、global.asax.csが無視されていました。

このサイトは、プリコンパイルされた.NET 2 Webサイトから.NET 4.0サイトにアップグレードされたことがわかりました。サーバーでは、PrecompiledApp.configファイルはルートフォルダから削除されていません。それを削除し、IISアプリプールをリサイクルしてweb.configを操作してアプリケーションを再起動すると、Global.asax.csのコードが正常に機能し始めました。

Global.asaxとGlobal.asax.csが実際に展開スクリプトによってIISフォルダーにコピーされないという問題がかつてありました。そのため、開発サーバーでデバッグするときに機能しましたが、IISの下では機能しませんでした。

遅いエントリー...

デバッガーが接続するのに十分な時間がある前にIISアプリケーションが開始されるかどうかをテストするには、これをGLOBAL.ASAXの上部または下部に追加するだけApplication_Startです。

throw new ApplicationException("Yup, it fired");

「デバッグ」とは、Visual Studioの組み込みWebサーバーから実際にアプリケーションを起動してデバッグすることを意味しますか、それともIISのプロセスにアタッチすることを意味しますか？前者の場合はApplication_Startを押す必要がありますが、後者の場合は、それをキャッチするのに十分早い段階でプロセスに入るのは難しい場合があります。

Visual Studioを閉じ、Webプロジェクト（またはソリューション内のすべてのプロジェクト）のbinおよびobjフォルダーを削除します。

これらのフォルダをすべてのプロジェクトから削除するコマンドを次に示します。

rm *\bin -r
rm *\obj -r

Visual Studioの「ビルドのコード分析」に基づいていくつかの変更を加えました。Code Analysisは、Global.asaxのApplication_Start（）に対して「CA1822メンバーを静的としてマークする」ことを提案しました。私はそれをして、そしてこの問題で終わりました。

このコード分析メッセージを抑制し、アプリケーションのブートストラップに使用されるプラットフォームによって自動的に作成されたメソッド/クラスのシグネチャを変更しないことをお勧めします。メソッドApplication_Startのシグネチャは、おそらく理由により静的ではありませんでした。

このメソッドシグネチャに戻したところ、Application_Start（）が再び発生していました。

    protected void Application_Start()
    { ... }

起動ページとして静的ページ（index.htmlなど）を使用すると、この問題に直面しました-Application-Startが呼び出されません。静的ページを提供しても実際にはアプリケーションが起動しないことがわかりました。.aspxページをリクエストすると、

Global.asaxとGlobal.asax.csの名前空間が同じであることを確認してください。それらが異なる場合、エラーはスローされませんが、application_startをまったく実行していないため、ブレークポイントに到達しません。

アプリケーションの開始イベントは、最初のリクエストが行われたときにのみ発生すると思います。Webサイトにアクセスしていますか（リクエストを行っていますか）？

私は.net 4 Webフォームvs2010プロジェクトでこの問題を抱えており、このページで言及されているすべてを試しました。結局、global.asaxを削除して追加すると、実際に問題が解決しました。

同じ問題が発生しましたが、Application_Startをキャッチできませんでした。そしてその理由は、それがマークアップファイルのミスマッチに対して実行されなかったからです。 マークアップファイルGlobal.asaxは別のクラスを継承していました...

プロジェクトの設定を確認しましたか？この問題が発生し、サーバー固有のポートとは異なるポートに開始URLが移動しました。理解するのに時間がかかりすぎました...

私の状況に当てはまる他の多くの答えを試してみて、どれもうまくいかなかった後、Webプロジェクト（RIAサービスを使用するSilverlightアプリのサーバー側プロジェクト）のプロパティに移動し、 「Web」タブをクリックして、選択したサーバーを「ローカルIIS」から「IIS Express」に変更しました。（私はVS2013を使用していることに注意してください。）これで問題は解決しました。Application_Startは「IIS Express」で実行されますが、「ローカルIIS」では実行されません。面白い...

アプリケーションの開始から呼び出されたRegisterRoutes（）のコードをステップスルーしようとしていて、ブレークポイントに到達しませんでした。Application_Startが呼び出されていないと判断しました。App_start / RouteConfig.csに表面的な変更を加え、Application_Startが呼び出される前に保存するように変更する必要がありました。これらのファイルはどこかにキャッシュされ、変更が行われない限り呼び出されないと思います。

System.Web.Routingプロジェクトにアセンブリの参照を追加することで、同じ問題が解決されました

System.Diagnostics.Debugger.Break（）;を使用している場合 回避策（これは一時的な使用では問題ないと思います）であり、Windows 8マシンでは「機能しない」だけです。その理由は、Visual Studioの「ジャストインタイムデバッグ」のバグです。

修正は次のとおりです。「Visual Studio Just-In-Time Debugger」のキーを修正します。

regeditを開き、「AppIDFlags」レジストリ値のHKEY_CLASSES_ROOT \ AppID {E62A7A31-6025-408E-87F6-81AEB0DC9347}に移動し、フラグを0x8に設定します

詳細はこちら： http : //connect.microsoft.com/VisualStudio/feedback/details/770786/just-in-time-debugging-operation-attempted-is-not-supported

私の場合、システムトレイを介して組み込みのASP.NET開発サーバーインスタンスを強制終了すると、問題が解決しました。

奇妙でクレイジーなもの...しかし、サーバーマシンと別のユーザーでのデバッグは、IIS Expressをセッション上で実行したままにしました。実行中のIIS Expressプロセスを強制終了するには、そのユーザーをログオフする必要がありました。これで問題が解決したようです！

更新

問題の原因を追跡するのに1時間以上費やした後、これが問題です。私は、なんとかしsての<appSettings>セクション内に内部を入力しましたWeb.config。Visual StudioはError Listウィンドウで警告を表示しようとしました。私はめったに警告をチェックしないと告白します...これからチェックを開始する必要があります。：D問題のsあるブレークポイントを削除するとすぐに、ブレークポイントがヒットしましたApplication_Start。

log4netを初期化しようとしたときにこの問題が発生しました。Global.asaxの静的コンストラクタを作成することにしました

static Global(){
//Do your initialization here statically
}

問題は主に、Global.asaxファイルを別のソリューションディレクトリに再配置しようとしたときに発生します。Global.asaxファイルをデフォルトの場所に再度移動します。期待どおりに動作します。

上記の解決策のどれも私にとってはうまくいきませんでした。ただし、パッケージを再インストールする

Microsoft.CodeDom.Providers.DotNetCompilerPlatform 

nuget guiの使用は（あまり良くない）ウォークアラウンドです