リフレクション プロバイダー ( http://msdn.microsoft.com/en-us/library/dd728281.aspx )を使用する手順に従って、クラス Order と Item をクラス ライブラリに移動し、クラス ライブラリを参照するまで、すべてがうまく機能します。 SVC ファイルを含む Web プロジェクトから。
POCO クラスを WCF プロジェクトに移動すると、すべてうまくいきます。
POCO クラスを WCF プロジェクトから別のアセンブリに移動すると、説明なしで 500 が返されます。
poco クラスを別のプロジェクトに保持し、OData エンドポイントで公開できるようにしたいと考えています。私は何を間違っていますか？
--UPDATE--
上記のシナリオは、WCF OData Reflection Provider を使用して発見した問題を説明するためのものです。それは私の本当の問題ではありませんが、説明のために簡単に説明できます。
WCF Data Services の最新バージョン (現在は 5.3) にまだアップグレードしていない場合は、アップグレードしてみてください。.Net 4.5 に同梱されているバージョンの WCF Data Services を使用して問題を再現しましたが、NuGet を使用して両方のアセンブリの参照を Microsoft.Data.Services の最新リリースにアップグレードすると、問題はなくなりました。
最新バージョンの WCF Data Services を既に使用している場合は、両方のアセンブリがまったく同じバージョンの WCF Data Services を参照していることを確認してください。
これらのいずれも問題を解決しない場合は、次の属性を DataService クラスに追加して、より詳細なエラー メッセージとスタック トレースを取得します。
[System.ServiceModel.ServiceBehavior(IncludeExceptionDetailInFaults = true)]
public class YourService : DataService<...>
そして、その結果で質問を更新してください (解決策がスタック トレースからすぐに飛び出さない場合)。
（免責事項：私は通常、あなたの問題を解決するのに役立たないような回答は好きではありませんが、あなたの問題が正しい問題ではない理由を説明しますが、この場合は正当だと思います:))
考えてみれば、そんなことはしたく
ありません。Order クラスと Item クラスは実際にはまったく POCO ではありません。それらは「プレーンな」C# オブジェクトではありません。それらにはデータ属性があり、データ転送オブジェクト(DTO) になります。
サービスとそのクライアントの間のインターフェースに属します。
ドメイン エンティティ (または POCO) の Item と Order は、おそらくもう少し複雑で、操作やビジネス ロジックなど、データ以外のものが含まれます。
Order と Item に属性と操作の完全なセットが含まれ、その上に、サービス クライアントが必要とする属性のみを含む DTO レイヤーがあるリッチ ドメイン モデルを使用するのが正しい方法だと思います。
POCO をネットワーク経由で送信することは「ストリッパー パターン」と呼ばれ、避けるのが最善だと思います。