2012-10-03 4 views
8

最近Azureに配備されたプロジェクトでは、これらの例外を2〜3回投げ始めました。私の調査によると、これは、一般的に、他のタイムゾーン(this was a good resource)のマシンに展開することによって発生する将来のタイムスタンプを持つアセンブリによって引き起こされることが判明しています。私たちは、今年の前半にこの問題を抱えていなかった+アプリが生きていて、ほんの一握りの例外が示唆するよりも多くのトラフィックを受け取りました。System.Web.HttpCachePolicy.UtcSetLastModified(DateTime utcDate)からのA​​zureのArgumentOutOfRangeException

リモートデスクトップを有効にして再展開し、私たちのdllのタイムスタンプと\ Windows \ Microsoft.NETおよび\ Windows \ assemblyディレクトリの内容をチェックし、 "将来の"タイムスタンプが見つからなかった。この時点で私は立ち往生し、アイデアに感謝します。

スタックトレース:

System.ArgumentOutOfRangeExceptionが:指定された引数が有効な値の範囲外でした。 パラメータ名:システムでSystem.Web.UI.Page.InitOutputCache(OutputCacheParametersのcacheSettings)でSystem.Web.HttpCachePolicy.SetLastModifiedでSystem.Web.HttpCachePolicy.UtcSetLastModifiedでutcDate (日時utcDate) (DateTimeの日付) 。 System.Web.MvcでSystem.Web.UI.Page.ProcessRequestでWeb.UI.Page.ProcessRequest(ブールincludeStagesBeforeAsyncPoint、ブールのincludeStagesAfterAsyncPoint) ()System.Web.UI.Page.ProcessRequest(のHttpContextコンテキスト)で 。 OutputCacheAttribute.OnResultExecuting(ResultExecutingContext filterContext) (System.Web.Mvc.ControlActionInvoker.InvokeActionResultFilter)(IResultFilterフィルター、ResultExecutingContext preContext、Func 1 continuation) at System.Web.Mvc.ControllerActionInvoker.InvokeActionResultFilter(IResultFilter filter, ResultExecutingContext preContext, Func 1続き)System.Web.Mvc.ControlActionInvoker.InvokeActionResultFilter(IResultFilterフィルター、ResultExecutingContext preContext、Func 1 continuation) at System.Web.Mvc.ControllerActionInvoker.InvokeActionResultWithFilters(ControllerContext controllerContext, IListフィルター、ActionResult actionResult) (System.Web.Mvc.Async.AsyncControllerActionInvoker) にあります。 <> c__DisplayClass27.b__24(IAsyncResult asyncResult) at System.Web.Mvc.AsyncController。 <> c__DisplayClass19.b__14(IAsyncResult asyncResult) at System.Web.Mvc.Async.AsyncResultWrapper。 <> System.Web.Mvc.Async.AsyncResultWrapperのSystem.Web.Mvc.AsyncController.EndExecuteCore(IAsyncResult asyncResult) のc__DisplayClass4.b__3(IAsyncResultAr) <> System.Web.Mvc.MvcHandlerのc__DisplayClass4.b__3(IAsyncResultAr) <> c__DisplayClass6。 <> c__DisplayClassb.b__4(IAsyncResult asyncResult) at System.Web.Mvc.Async.AsyncResultWrapper。 <> c__DisplayClass4.b__3 System.Web.HttpApplication.ExecuteStepでSystem.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() で(たIAsyncResultのAR) (IExecutionStepステップ、ブール& completedSynchronously)

+0

私は」私は同じ問題を見ている。 System.Web.HttpCachePolicyとSystem.Web.UI.Pageコード(SSCLI経由)を見て、これは不可能であるはずです。この例外は、最終更新日を将来の日付に設定しようとするとスローされます(DateTime.UtcNowより大きい)。フレームワークが要求の開始時にDateTime.UtcNowに設定されているHttpContext.Timestampを使用するため、これは決して起こりません。リクエストの処理中にNTP(時刻同期)が実行される可能性があります。 –

+0

テーブルのストレージにデータを格納していますか?DatetimeがUTC時刻の正しい形式であるかどうかを確認してください。また、Datetimeを文字列に変換してテストします – user145610

答えて

0

Azure環境では、タイムゾーンの問題は本当に頭痛です。開始タスクを追加し、Azure環境のタイムゾーンを変更することをお勧めします。私はこれがあなたの問題を解決すると主張していないが、それを試して傷ついていないのですか? Azure環境のタイムゾーンを変更するには

1)tzutil /s "Pacific Standard Time"を.cmdとして保存し、プロジェクトにファイルを含めます。

2)ファイルのプロパティ画面で、[出力にコピー]オプションとして[常にコピー]を選択し、ビルドアクションとして[なし]を選択します。

3)あなたのサービス定義ファイルに以下を追加します。

<Startup> 
    <Task commandLine="nameOfFileYouCreated.cmd" executionContext="elevated" /> 
</Startup> 

4)そしてもちろん、あなたのプロジェクトであなたのDateTime参照を適応させる、コンバージョンに対処する必要はありませんなど

関連する問題