私は紺碧でウェブの役割を果たしています。開発アプリケーションではローカルで正常に動作していますが、Azureにデプロイされたときは何も応答しません。Azure Webロールが起動したときのエラーを追跡する方法は？
私はそれがweb.configに何らかの問題があると想定していますが、それが非常に早く起こっているので、グローバルasaxで診断用の設定を行う前にすでに発生しています。言ったように、それはローカルでうまく動作していますが、紺碧のシステムからの応答は全くありません。
例外テキスト、スタックトレース、IISアプリケーションシステムのエラーログ、または実際の問題を暗示できる何かを得るように、具体的に何が間違っているのかを知るにはどうすればよいですか？
Webロールで実行される絶対的なものは、アプリケーションではなくAzureプロジェクトのWebRole.csのOnStart()メソッドです。これは、Webサイトを監視するコードを追加する場所です。
標準的な手法は、アプリケーショントレースログとWindowsイベントログを、Azureテーブルストレージに（必要に応じて）CPU使用率、IIS統計情報、およびwhat-have-youと一緒にコピーすることです。 http://blog.bareweb.eu/2011/01/beginning-azure-diagnostics/
、あなたのアプリケーションで必要があります仕様の詳細との良好なフォローはこちら：：
これまでの良好な導入はここにあるのAzure SDK 1.5には適用ままhttp://blog.bareweb.eu/2011/03/implementing-azure-diagnostics-with-sdk-v1-4/
。
診断をキャプチャしたら、Visual Studioを使用して直接表示するか、Cerebrata Azure Diagnostics Managerのようなツールを使用して自動的にグラフ化してフィルタリングすることができます。このツールは、（特に、複数のインスタンスを持つ大規模なシステムの場合、グラフは実際には有用ではありませんが）エッジの周りに少し荒いですが、現時点で得られるほど良好です。
代替方法として、リモートデスクトップを使用してリモートインスタンスに接続し、Windowsのイベントログなどでいくつかのスペルンクを行う方法があります。また、リモートインスタンス上にあるInternet Explorerブラウザを使用して、アプリケーションにローカルで直接接続し、隠されている可能性のあるエラーなどを表示することもできます。
診断ストレージ・メカニズムが機能していない場合は個人的に私はこれだけにしてください：運用サーバーは、実際のリモートデスクトップアクセスは、外部からの攻撃のための可能な面積を減らすために完全にオフになっているはずです。
診断を設定することは、アプリケーションのトラッキングエラーを処理する最長期の解決策です。何かアドホックなものをご希望の場合は、catch the errors and write them to blob storageか、ご自身のlight weight trace listenerをご利用ください。
問題はアプリケーションがクラッシュしてから*私がトレースコードを起動できることでした。 –
それは毎回あなたを得るでしょう... – knightpfhor
リモートデスクトップでは、エラーをトレースすることができました。問題は、アプリケーションの起動時にアセンブリ参照が間違っていたことです（誤ったアセンブリバージョン）。それは他のコードが実行される前に起こっていたので、少しトリッキーでしたが、sysログから見つけました。 –
良いキャッチ、素敵な1つ - 私はレーダーの下で盗んだ不正な32ビットのアセンブリと一点で同様の問題を抱えていた。 –