ExecuteStoreQuery
現在のデータベースの日付を取得するために使用すると、次の例外が発生します。
The types in the assembly 'XYZ' cannot be loaded because the assembly contains
the EdmSchemaAttribute, and the closure of types is being loaded by name.
Loading by both name and attribute is not allowed.
at System.Data.Metadata.Edm.ObjectItemCollection.LoadAssemblyFromCache(
ObjectItemCollection objectItemCollection, Assembly assembly,
Boolean loadReferencedAssemblies, EdmItemCollection edmItemCollection,
Action`1 logLoadMessage)
at System.Data.Metadata.Edm.MetadataWorkspace.ImplicitLoadAssemblyForType(
Type type, Assembly callingAssembly)
at System.Data.Objects.ObjectContext.ExecuteStoreQueryInternal[TElement](
String commandText, String entitySetName, MergeOption mergeOption,
Object[] parameters)
at (my method)
問題のメソッドが含まれている場所
var timestamp = context.ExecuteStoreQuery<DateTime>("SELECT GetDate() ").First();
以前に正規関数を使用CurrentDateTime
したことがありますが、デバッグ構成でもこの例外が発生しました。現在は release config でのみスローされます。
この正確な例外が数回しか言及されていないことがわかりました。ほとんどの場合、1 つのアセンブリでコード ファーストとデータベース ファーストのアプローチが混在していることに関連していましたが、私の場合は除外したと思います。
生成されたコードには実際に
[assembly: EdmSchemaAttribute()]
しかし、どのタイプがそれを引き起こしたのかわかりません-私は何も知らず、それらを見つける方法も知りません.
LINQ to Entities のみを使用すると、すべてうまくいくようです。
当分の間、私はサーバー時刻が同期されていることに依存しており、DB 時刻をまったくクエリしていません。
そして質問:
コード ジェネレーターが前述の属性を含める原因は何ですか? どうすればそれを防ぐことができますか? 合理的な回避策は何ですか (ストアド プロシージャをインポートするSELECT GetDate()
のはやり過ぎのようです)。また、これがリリース構成でのみ発生するのはなぜですか? コンパイラのシンボルとオプションに基づくEFの最適化/違いに関する情報は見つかりませんでした...