私は C# .net 4.0 を使用していますが、それを行う方法がわかりませんが、ご存知でしょうか? :)
私はその方法でシリアライゼーションを行います：

デシリアライズ/シリアライズにのみ必要なデータを格納するためにクラスにフィールドを追加することを回避できますか？

私がいくつかのクラスを持っているとしましょう：

serializableTemporaryDataの各オブジェクトにフィールドが含まれないようにする方法はありMyClassますか？たとえば、静的にすることはできますか（おそらく、On ...メソッドを変更することによって）？

制約：の実装を変更することはできませんNonSerializableDataType。

例：myFieldにリソースへのハンドルが含まれているとします。次に、シリアル化の際に、逆シリアル化後にリソースを取得する方法に関する情報を保存する必要がありますが、ハンドル自体を保存することはできません。ハンドルを別のクラスにラップすると、問題がラッパークラスに移されただけです。その場合、ラッパークラスについてもまったく同じ質問をします。

私のアプリケーションの認証コード内で、FormsAuthentication最も複雑な部分を処理するために使用して、アプリケーションを実行している特定のマシンの環境問題の原因を BinaryFormatter に絞り込みました。

On some machines the auth process completes properly and my users are logged in. On others, however, the BinaryFormatter produces separate results from the same inputs (virtually identical, unless I'm missing something), thus breaking the auth process and users can never log in.

In the correct environment, it produces a serialized string with a length of about 373. In the bad environment, the serialized string produced is 5,024. Herein lies the problem.

Here's how the code is being run:

This in turn mucks up the rest of the authentication process, because it essentially creates a cookie with about 40,000+ bytes of data, which never creates a cookie (needs to be 4,096 bytes or less to be accepted by the browser).

My question, and it's not easily testable (tell me about it) - what could be different between the two machines to cause serialization differences? Both are being developed on Windows 7 in Visual Studio and running on the built-in Cassini server, but are there other common gotchas that would make Serialize return such vastly different results?

Windows ベースのチャット アプリケーションを開発しています。クライアントが最初に Command クラスを送信すると、サーバーはそれを処理し、別の Command クラスを送信してクライアントに確認応答します。

(プログラムの流れがわかるように、コード セグメントに番号を付けました)

サーバーが確認を送り返すまで、すべてがうまくいきます。クライアント (5.) でコードを実行して、逆シリアル化して確認応答のコピーを取得すると、クライアント プログラムが応答しなくなります。しかし、サーバーのコード (6.) は機能しているようです。コマンドを正常にシリアル化します。

誰かがここで何が悪いのか指摘できますか?

前もって感謝します。

サーバーコード:

クライアントコード:

サーバーがMS.NETで実行され、クライアントがMono（これはUnity3Dエンジンです）で実行されており、BinaryFormatter（）を実行しようとすると、次のようにオブジェクトを逆シリアル化します。

クライアント側がタイプを検出/ロードできません：ディクショナリ、リスト... MS.NETで実行されているのと同じ「クライアントコード」が正常に機能します。つまり、逆シリアル化中に例外が発生しません。

http://www.mono-project.com/FAQ:_Technical#Compatibilityから読んだように、これは一般的な問題です。

「独自のクラスをシリアル化する場合は、シリアル化に使用されるアセンブリとクラスを制御できるため、問題はありません。ただし、フレームワークからオブジェクトをシリアル化する場合は、内部構造がこれらのオブジェクトは異なる場合があります。この互換性は、異なるMS.NETバージョンまたはMonoバージョン間でも保証されません。」

ProtoBuf-Netは、このシリアル化/逆シリアル化の問題を回避/解決するのに役立ちますか？

DateRange以下に示すように、静的参照を介して無限の概念を表すオブジェクトがあります。ご覧のとおり、Infinity を定義するエンド ポイントは、別のクラスの静的参照でもDatePoint.PastありDatePoint.Futureます。

ここで、これをシリアライズし (シリアライゼーションを使用するディープ Clone メソッドの一部として)、エンドポイントを持つインスタンスがデシリアライズされるタイミングを知る必要がありますDateTime.MinDateTime.MaxDateRange.Infinity。だから私はそれを作る必要があると思いますISerializable。

私の最初の実装の試みISerializableはかなり貧弱です。しかし、私はそれが誰かにとってより迅速な修正を示唆することを期待してそれを示しています. NHibernate が db に格納して Infinity を再構成するためにいくつかの同様のコードを使用しDateRangeましたが、それをシリアル化に適用する方法はまだわかりません。

DatePointはマークされ[Serializable]ていますが、実装していませんISerializable。

編集された質問

インフィニティをシリアライズ/デシリアライズするつもりはありません。私が探しているのは、逆シリアル化されたものを取り、DataRangeそれが と同等かどうかを判断できる場所へのフックInfinityです。

**

乾杯、ベリル

日付範囲

日付ポイント

最初の ISerializable 試行

現在、クラスUsageDataをバイト配列に保存し、ハードウェア キーに保存する作業を行っています。このハードウェア キーには、ユーザー データ用に最大 256 バイトが予約されています。現在、プロパティで満たされたクラスのサイズは約 640 バイトで、既に圧縮されています。UsageDataTempここで、プロパティ/フィールドなしで一時的なクラスを作成しました。バイト配列が値なしでどれだけ大きいかを確認するテストを実行すると、すでに 220 バイトのサイズがあり、あと 36 バイトしか残っていません。

値のない空のクラスが、それ自体を保存するためにすでに 220 バイトを必要とするのはなぜですか。また、バイト配列をさらに圧縮する方法はありますか。それとも、自分で作成を開始する必要がありますかBinaryFormatter。

.NETを使用してBinaryFormatter、Convert.ToBase64Stringカスタムオブジェクトをシリアル化<input>し、Webページの非表示タグに格納しています。

ユーザーがフォームを送信したら、手順を逆にしてカスタムオブジェクトを逆シリアル化します。

ギャップのあるセキュリティホール：ユーザーがインスタンスを巧みにシリアル化MyMaliciousTypeしてbase-64文字列に変換し、それをWebフォームに投稿するとどうなるでしょうか。

デシリアライズを実際に実行する前に、デシリアライズされるタイプが特定のタイプと一致するかどうかを確認する方法はありますか？

私は、同じコンピューター上にある2つの単純なプログラム間にリモートチャネルを確立するためにを使用RemotingServices.Marshalしています。Activator.GetObject

number両方のプログラムが正常に変更さtextれ、完全に一意の値に変更されているため、チャネルが存在し、通信が可能であることを確認しました（確認済み）。

だから私はすぐに同じことをしようとしましたstrings。

あるプログラムで、私はに電話しstrings.Add("1")ました。strings2番目のプログラムの内容を読んでみました。空でした。さらに、カウントはでした0。オブジェクトを追加しなかったかのように、なぜオブジェクトstringsが継続するのかわかりません。0同じことがaStack<T>とDictionary<T, K>、にも起こります。要素を追加することはできません。一般に参照型で何か奇妙なことが起こっていないことを確認するためStringBuilderに、IPCイン​​ターフェイスクラスにを入れてみました。その「状態」は、値を変更する両方のプログラムで正常に維持されました。

質問：文字列のリストが追加されないのはなぜですか、そして解決策は何ですか？

経験のある人がこの問題をすぐに見つけられることを願っています。同様の質問でグーグルを試しましたが、有用な結果は得られませんでした。驚いたことに、「. netremotingtransparentproxyのデバッグ」をグーグルで検索するための適切なリンクは1つしかありませんでした。それも私が持っている2番目の質問です。透過プロキシオブジェクトをデバッグするにはどうすればよいですか？

1. すべてのオブジェクトは適切にインスタンス化されます（NullReferenceExceptionはありません。実際、例外はありません）。

私はカードゲームプログラムを持っていますが、これまでのところ、チャットはホストとクライアントの間のTCPClientストリームを介してうまく機能します。ホストとクライアント間でカードを渡すこともできるように、シリアル化と逆シリアル化を使用してこれを実行したいと思います。カードを渡すために別のTCPClientストリームを作成しようとしましたが、機能せず、テキストメッセージとカードを取得する1つのTCPClientストリームを保持する方が簡単であると考えました。そこで、シリアルと呼ばれるクラスを作成しました。このクラスには、カードのプロパティがあり、もう一方の端にあるカードの埋め込みデータベースからカードを再構築するのに役立ちます。カードがストリームに入れられたかどうか、またはカードがストリームに入れられたかどうかをプログラムに認識させる方法はありますか？ストリーム内のテキストだけなので、文字列またはシリアルに適切に逆シリアル化できますか？または、シリアルクラスに文字列プロパティを追加する必要があります。シリアルに逆シリアル化した後にそのプロパティが入力されると、それは単なるテキストであることがわかります（逆シリアル化後にそのフィールドが空の場合は、カードであることがわかります）。文字列に逆シリアル化しようとするtrycatchを考えています。失敗した場合は、キャッチしてシリアルとしてキャストします。それとも、私はこれでベースから離れて、別のルートを選択する必要がありますか？Visual Studio 2011を使用していて、binaryformatterを使用していて、シリアル化/逆シリアル化を初めて使用しています。それが失敗した場合、それは穀物として捕らえられ、投げられます。それとも、私はこれでベースから離れて、別のルートを選択する必要がありますか？Visual Studio 2011を使用していて、binaryformatterを使用していて、シリアル化/逆シリアル化を初めて使用しています。それが失敗した場合、それは穀物として捕らえられ、投げられます。それとも、私はこれでベースから離れて、別のルートを選択する必要がありますか？Visual Studio 2011を使用していて、binaryformatterを使用していて、シリアル化/逆シリアル化を初めて使用しています。