問題タブ [devforce]

Devforce WindowsStoreDevTour サンプル アプリケーションを実行しようとしています。ただし、この例外が発生しています：

System.TypeInitializationException はユーザー コードによって処理されませんでした HResult=-2146233036 Message='WindowsStoreDevTour.NorthwindIBEntities' の型初期化子が例外をスローしました。Source=WindowsStoreDevTour TypeName=WindowsStoreDevTour.NorthwindIBEntities StackTrace: WindowsStoreDevTour.NorthwindIBEntities..ctor(Boolean shouldConnect, String dataSourceExtension, EntityServiceOption entityServiceOption, String compositionContextName) で WindowsStoreDevTour.DataService..ctor() で WindowsStoreDevTour.DataService.get_Instance() で WindowsStoreDevTour. ListPage.d__0.MoveNext() InnerException: System.TypeInitializationException HResult=-2146233036 Message='IdeaBlade.EntityModel.EntityMetadataStore' の型初期化子が例外をスローしました。ソース = IdeaBlade.EntityModel. WinRT TypeName=IdeaBlade.EntityModel.EntityMetadataStore StackTrace: IdeaBlade.EntityModel.EntityMetadataStore.get_Instance() で IdeaBlade.EntityModel.EntityRelation.get_MetadataStore() で IdeaBlade.EntityModel.EntityRelation.InitializeEntityRelations(アセンブリ アセンブリ) で WindowsStoreDevTour.NorthwindIBEntities..cctor( ) InnerException: System.Reflection.ReflectionTypeLoadException HResult=-2146232830 Message=1 つ以上の要求された型を読み込めません。詳細については、LoaderExceptions プロパティを取得してください。ソース = mscorlib StackTrace: IdeaBlade の System.Reflection.RuntimeAssembly.get_DefinedTypes() の System.Reflection.RuntimeModule.GetTypes(RuntimeModule モジュール) で。2.MoveNext() at System.Linq.Enumerable.FirstOrDefault[TSource](IEnumerable1 ソース、Func`2 述語) の IdeaBlade.Core.PlatformResolver.Resolve[T](Boolean throwIfNotFound) の IdeaBlade.Core.AppEnv.get_Current() の IdeaBlade.EntityModel.EntityMetadataStore..ctor() の IdeaBlade.EntityModel.EntityMetadataStore ..cctor() 内部例外:

解決方法がわかりません。

ASP.NET 要求でエンティティ マネージャーを使用するための現在のアドバイスは、AuthorizedThreadIDプロパティをNULL(参照1および2 ) に設定することです。それは機能しますが、非常に重要な「セーフティネット」を無効にしているようです. 私は Entity Manager をスレッドセーフな方法で使用するために非常に努力していますが、間違った場合に備えてセーフティネットを用意しておくと便利ですNULL....

ASP.NET の世界では、まだ大まかに 1 つの実行スレッドがあります。非同期作業を行っているときに実際のスレッドが変わる可能性があるだけです。いくつかの可能な解決策を考えることができます：

1. このEntityManager.SafeThreadingCheck()メソッドは、ASP.NET 要求をサポートするために、ある種の特別な魔法を行います。IdeaBlade がこれを行いたくない可能性があることは理解できます...これが 2 番目のオプションにつながります...
2. EntityManagerSafeThreadingCheck()エンティティマネージャがまだリクエストスレッド上に「論理的に」あることを確認するための特別な魔法を実装できる独自のバージョンを提供するためのいくつかの拡張ポイントを提供します。ここで奇妙なことをしなければならないかもしれませんが、それほど複雑になるとは思いません。
3. FancySafeThreadingCheck()独自のメソッドをいつ呼び出す必要があるかを検出するために、他の拡張ポイントを使用しようとしています。これには、必要なすべての場所に接続しようとする必要があるという欠点がありますが、既存のSafeThreadingCheck()メソッドは、必要なすべての場所から正確に最適なタイミングで (おそらく) 既に呼び出されています。

これが最優先の機能要求ではないことは理解できますが、それほど難しくないようにも思われます (少なくともオプション #2 の場合)。それとも、もっと良いかもしれない他の回避策がいくつかありますか? 私の最終目標は、この安全チェックをオフにしないことです...私はそこに到達するためのオプションを受け入れています。

DevForce リクエストがタイムアウトすると、自動的に再試行されることがわかりました。この動作は、こちらのフォーラムでも言及されています。そのフォーラムの投稿で提案されている解決策は、タイムアウトを増やして問題を完全に回避することです。私たちにとって、それは本当に可能な解決策ではありません。タイムアウトになることがわかっている操作がいくつかあり、タイムアウトを増やすことは受け入れられる解決策ではありません。

さらに悪いことに、呼び出しがストアド プロシージャ クエリまたは InvokeServerMethod 呼び出しである場合、呼び出しがべき等でない可能性が非常に高くなります。したがって、再試行は安全ではなく、結果的に害を及ぼす可能性が非常に高くなります。アプリでそのようなケースが発生し始めており、大きな問題を引き起こしています。簡単な例は次のとおりです。アイテムのコピーを作成するストアド プロシージャを呼び出します。コピーに時間がかかりすぎると、再試行が繰り返されますが、これは、3 つのコピー操作がすべて並行して行われていることを意味します。最終結果は、エンド ユーザーがエラーを受け取ることです (3 回目の rety がまだタイムアウトするため) が、(最終的に) アイテムの 3 つのコピーが存在します (ストアド プロシージャは最終的に終了します - 再試行ロジックは、以前のリクエスト - そのようなキャンセルが可能かどうかさえわかりません)。これはより良性の例の 1 つです。別のケースでは、再試行された操作がさらに悪い問題を引き起こす可能性があります。

6.1.6 リリース ノートから、 DevForceが保存の自動再試行を実行しなくなったことがわかります。その動作が StoredProcedureQueries と InvokeServerMethods に拡張されることを本当に望んでいます。通常の EntityQuery 操作 (およびおそらく Connect/Disconnect 呼び出しでさえ) では、rety で問題ありません。これが DevForce のコアで変更できるものではない場合、構成可能にする方法や、これを制御するコードを挿入するためのカスタム方法を提供する方法はありますか?

これは、ここの DevForce フォーラムからのスレッドのさらに別の続きです。問題は、変更がクエリまたはインポートによってトリガーされた場合、DevForce が EntityManager.EntityChanged イベントによってスローされる例外を黙って飲み込むことです。関連するコードは次のようになります。

フォーラム スレッドで言及されているように、このメソッドの動作は少しずつ変更されています。私が最初にこれについて不平を言ったときよりも、今は飲み込むものが少なくなっています。しかし、私たちのアプリケーションでは、何か問題が発生したときにそれを知る必要があります。クエリまたはインポート操作を行ったときにたまたまうまくいかなかったからといって、例外を気にしないという意味ではありません。

前回のフォーラム投稿では、この動作の根拠は次のとおりでした。

AddOnQuery (および AddOnImport) 中にスローされた例外を飲み込むための議論は、「クエリの途中で失敗することは通常、開発者が実際に意図したものではない」というものでした。

おそらく私たちはいつもとは違います :-) が、私たちのアプリケーションでは、イベント ハンドラーは次のようになります。

ここでスローされる例外は、イベント ハンドラーの書き方が悪いためではありません。ここで例外がスローされるのは、1 回限りの初期化ロジックを実行中にエンティティが非常に混乱したためです。そして、その論理の誤りは私たちにとって非常に重要です。

これを普遍的に変更することは危険であり、他のアプリケーションが壊れ始める可能性があることは理解できます。しかし、この動作をオフにする方法や、Entity Manager に例外を飲み込まないように指示する方法があれば、非常に役に立ちます。

以前の回避策は失敗し始めています。Web サービスですべてのビジネス ロジックを使用しようとしているためです。この種の処理をエラー ログだけに頼ることはできません。DevForce が潜在的に致命的なエラーを飲み込んだという理由だけで、呼び出し元に「成功」​​の応答を返すことはできません。

DevForce の最新バージョンを使用しています (この記事の執筆時点: 2012 - 7.2.3)。

無料の Windows ストア ライセンスを使用して、基本的な DevForce Windows ストア アプリケーションを使用しています。

Web プロジェクトとして実行すると、クエリを正常に実行できました。

ただし、ServerConsole.exe を使用してホストすると、次の例外が発生します。

http://localhost:63191/EntityService.svc/winrtこのアプリケーションからの呼び出しを受け入れることができるリッスンしているエンドポイントはありません 。Visual Studio で実行している場合は、Web プロジェクト内のすべての IdeaBlade アセンブリ参照に対して CopyLocal=true が設定されていることを確認して、これらのアセンブリが bin フォルダーにコピーされるようにします。また、global.asax に DevForce VirtualPathProvider を登録するコードが含まれていること、または EntityService.svc ファイルと EntityServer.svc ファイルが存在することも確認してください。
サービスが実行されているかどうかを確認するには、インターネット ブラウザを開いて次の場所に移動します。http://localhost:63191/EntityService.svc. サービス ページにエラーが表示された場合は、サービスの問題を診断するのに役立ちます。サービスが実行されている場合は、エンドポイント バインディングがクライアントとサーバー間で一致していること、およびサーバーの ClientApplicationType が「All」またはこのクライアントに対して正しいことも確認してください。詳細については、サーバーのデバッグ ログ ファイルを確認してください。

ソリューションには、App1 (Windows ストア)、DomainModel (NET4.5)、および App1.Web (Web アプリケーション) の 3 つのプロジェクトがあります。ServiceConsole.exe が DomainModel の出力ディレクトリにコピーされました。

ServerConsole は次のことを正しく報告します。

へのナビゲート

ソリューションのパッケージ マネージャー コンソールで Update-Database を実行すると、次のエラーが表示されます。

プログラムで更新を実行し、その例外をキャッチすることで、より多くの情報を取得できる場合があるという他の同様のスタックオーバーフローの議論を読んだので、これを試しました:

上記のコードは、実際には問題なく更新を正常に実行します (アプリケーションの初期化時に Web ブラウザーによって実行された場合の移行も同様です) が、パッケージ マネージャーは同じ Update-Database コマンドで同じエラーで失敗します。スタートアップ プロジェクト、デフォルト プロジェクト、コピー ローカル設定の参照、ibmmx ファイルの再生成、データベースの復元、ビジュアル スタジオ/OS の複数回の再起動を確認しました。また、powershell を介して例外情報にアクセスしようとしましたが、何も見つかりませんでした。パッケージ マネージャーの操作が失敗する理由に関する詳細情報を取得する方法を知っている人はいますか?

同じ基礎となるデータベース状態 (両方とも localhost 上に異なるデータベース サーバー) を使用したこの同じセットアップは、別の開発マシンでも問題なく動作するため、私のセットアップまたはインストールに固有のもののようです。他に知っておくべき「落とし穴」はありますか?

ありがとう。

更新: パッケージ マネージャーの外部で動作する移行については、早すぎたかもしれません。動作中の開発マシンで作成し、ローカル マシンにプルしたところ、Web ブラウザーまたはパッケージ マネージャーでアプリケーションを初期化しても機能しないことがわかりました。

呼び出しの一部として特定のエンティティをサーバーに送信するときに、さまざまなStackOverflowExceptionandが発生しています。この問題は、DevForce が予想よりも多くのデータをシリアル化しようとするために発生したようです。に保存されているデータまで追跡しました。OutOfMemoryExceptionInvokeServerMethodOriginalValuesMap

元の値はDataEntityProperties、エンティティに追加したものですが、 でマークされて[DataMember]いないため、通常はサーバーに送信されません。 しかし、既存の (以前に保存されたエンティティ)があり、それらのプロパティの 1 つを変更すると、プロパティの初期値はOriginalValuesMap. 元の値が巨大なエンティティ グラフを持つエンティティであることが判明するため、これは大きな問題を引き起こしています。

問題に加えて、私たちが扱っているエンティティは、実際に((ICloneable)origEntity).Clone()は既存の (以前に保存された) エンティティの ( による) クローンであるため、切り離された状態になり、OriginalValuesMap切り離されたエンティティの をクリアする方法が見つかりませんでした。通常はそうしますmyEntity.EntityAspect.AcceptChanges()が、切り離されたエンティティには何もしません。これを行う簡単な方法が他に見つかりませんでした。

これまでのところ、元の値をクリアする唯一の方法は、エンティティをエンティティ マネージャーにアタッチすることです。これは元の値をクリアすることになりますが、実際には多数のエンティティを扱っているため（パフォーマンスが懸念されます）、これらのエンティティの多くは一意の主キー値を持っていないため（実際には、実際に保存する予定のない「メモリ内」オブジェクトであるため、キー値が入力されていないため、エンティティに追加するときに「重複キー例外」エラーを回避するために追加の作業を行う必要がありますマネジャー。

切り離されたエンティティの元の値をクリアできる他の方法はありますか? それとも、AcceptChanges のようなものが切り離されたエンティティに対しても機能しない場合、切り離されたエンティティは最初から元の値を追跡する必要がありますか? それとも、複製されたエンティティは、そのソースの元の値を「継承」してはならないのでしょうか? 私はこれらの可能性のどちらについても強い意見を持っていません...エンティティをシリアル化できるようにしたいだけです。

私たちのアプリは、DevForce 2012 v7.2.4.0 を実行する Silverlight クライアントです。