問題タブ [sgen]

「最初の」逆シリアル化の時間の無駄を避けたいのでsgen.exe、アセンブリの作成に成功しました。MyLibrary.XmlSerializer.dll

しかし、今、それをどのように使用するのですか？

つまり、使用するにはどこに置くMyLibrary.XmlSerializer.dll必要がありますか？どうすれば確実ですか？

ありがとう！

SGEN で生成されたアセンブリを使用する場合、リストをシリアル化するにはどうすればよいですか?

アセンブリを生成した後、PersonSerilizer などのクラスにアクセスし、1 つのオブジェクトをシリアル化できますが、このオブジェクトのリストをシリアル化するにはどうすればよいでしょうか?

どんな助けでも大歓迎です。

良い一日、

プロジェクトをリリース モードでビルドしようとしていますが、タイトルに記載されているエラーが発生し続けます。これは何が原因で、どうすれば防止または修正できますか?

このようなstackoverflowで見た他の回答は、私には意味がありませんでした。

生成されたシリアライゼーション .dll に奇妙な問題があります。.dll が正常に生成され、プロジェクトで参照できます。すべての型がMicrosoft.Xml.Serialization.GeneratedAssembly期待どおりに名前空間に含まれており、インテリセンスが型と名前空間を取得しています。しかし、生成されたアセンブリ内のいずれかの型を参照するプロジェクトをビルドしようとすると、次の行に沿ってエラーが発生します。

エラー 2型または名前空間名 'Xml' が名前空間 'Microsoft' に存在しません (アセンブリ参照がありませんか?)

かなり奇妙ですよね？インテリセンスに関する限り、名前空間は明らかに存在し、これまでにこのような問題が発生したことはありません。アセンブリを再生成しようとしましたが、それでも同じ問題です。

今のところsgen.exe、フラグ/keepを付けて実行し、生成されたソースをプロジェクトにコピーしましたが、問題ありません。この問題を修正する方法があるかどうか、または他の誰かが以前に遭遇したことがあるかどうかに興味がありました.

編集:

生成されたアセンブリが、それを参照しているアセンブリよりも新しいバージョンの .NET フレームワークをターゲットにしているため、問題が発生していることが判明しました。問題は、特定の .NET フレームワーク バージョンを対象とするシリアル化アセンブリを Sgen で生成するにはどうすればよいかということです。

Debian Wheezy Mono-Sgen 2.10.8.1-8 組み込みアプリケーションのメモリ リークかどうかを判断するのに苦労しています。システムには 512MB の RAM があります。スワップは無効です。私は、Linux がプロセス メモリをどのように管理しているかを理解しようと研究しており、実際に Mono-Sgen のどこかでメモリ リークが発生しているかどうかを結論付けています。何週間にもわたる一定の実行時間の後に何度もプロファイリングしており、GC メモリは常にアプリケーションのベースラインに戻っているため、これが私のアプリケーションではないことは間違いありません。私のアプリケーションの観点からは、オブジェクトがリークしていません。これは、Mono-Sgen が内部的にリークしていないという意味ではありませんが、私はこれを特定していませんし、そうではない可能性もあります。

大きなヒープの mono のデフォルトは 512MB であるため、Mono-Sgen ヒープの上限を設定しようとしましたが、これが私のシステムのすべてであるため、Linux からの OOM を防ぐために上限を設定する必要があると想定しました。Mono-Sgen の構成は次のとおりです。

export MONO_GC_PARAMS=major=marksweep-fixed,major-heap-size=32m,nursery-size=4m,evacuation-threshold=75

私の理解では、32MB 固定サイズのマーク アンド スイープ固定メジャー ヒープを使用しています。デフォルトのナーサリ サイズは 4MB であり、メジャー ヒープ割り当てバケットのいずれかが 75 を下回った場合、Mono-Sgen はメジャー ヒープでコピー コレクションを実行します。断片化を防ぐために使用される %。デフォルトの 66% を上げました。

停電によりリセットが発生してから、私のデバイスは現在 6 日強稼働しています。アプリケーションが最初に起動するとき、完全に初期化されるまで約 10 分待ってから、/proc/PID/status ファイルのスナップショットを撮り、メモリ使用量のベースラインを取得します。今日、私は別のスナップ ショップを利用して現在の状況を確認しました。いつものように、Mono-Sgen プロセスのこのインスタンスの仮想、常駐、およびデータが再び増加しました。初期化中に発生した最高水位標をまだ破っていませんが、前回このテストを行ったときは破っていました。私ができなかったことと、達成しようとしているのは、システムのすべての物理メモリを使い果たすまで実行させることです。これが実際にメモリ リークなのか、それともある時点で Linux が私のプロセスが割り当てたページの一部を再利用するのかを知る必要があります。

私が気づいたことの 1 つは、スワップがないことを知っていても、Mono-Sgen プロセスの常駐サイズが常にデータ数より約 30MB 少ないことです。私が理解していることから、データ数はヒープ割り当ての量であり、常駐サイズは実際に物理メモリにあるものであり、仮想は割り当てられたものであり、必ずしも使用されるわけではありません。

私の推測では、Linux は単に Linux であり、必要な場合を除き、時間やメモリを無駄にすることはありません。システムの負荷が非常に軽いため、Linux はメモリを再利用するために何かを行うメモリ プレッシャーがなく、Mono-Sgen がヒープの割り当てと拡大を続けないようにするためだと思います。実際のメモリ プレッシャーがある場合、Linux は実際には使用されていないページに足を踏み入れて再利用します。

以前に割り当てられたメモリで free が呼び出された場合、Linux はプロセスの割り当てられたメモリ サイズを縮小しないことを読みました。LinuxがLinuxでない限り、必要な場合にのみ実行する理由がわかりません。しかし、私の恐れは、これが起こるまでどれだけ待つ必要があるかということです.

これはメモリ リークですか? それとも、メモリ プレッシャーが発生し始めたときに、このプロセスの常駐サイズとデータ サイズの間で見られるページの違いを Linux が再利用しますか? この件について手に入れることができるすべてのものを検索して読みましたが、探している答えが見つからず、OOMキラーが原因でアプリケーションがバウンスするかどうかを確認するのに1か月も待ちたくありません. とにかくします:)しかし、事前に知りたいです。

私は Mono-Sgen 2.10.8.1-8 で潜在的なメモリ リークを調査しましたが、私がやっていること (ネイティブ Linux アプリケーションへの多数の process.start() 呼び出しを使用) については、私を傷つけるタイプのバグのほとんどを調べました。このリリースにはありません。Jessie の Mono-Sgen バージョン (3.2.8 だと思います) に更新しようとしましたが、システムがクラッシュしていたので、未知の恐怖から安定した Mono-Sgen 2.10.8.1-8 バージョンに戻しました。

/proc/PID/status によって返される内容に注目して、典型的なメモリ情報のスナップショットを多数添付しています。

いつものように、どんな情報でも大歓迎です。Linux が負荷の軽いシステムでメモリを再利用する方法を理解していないことを願っています。

web.config の書き換えセクションで OutboundRules を有効にして、すべての .html 拡張子を拡張子なしに変換しようとしています。

ただし、ルールを追加すると (内容は関係ありません)、.XmlSerializers.dll が見つからないことを示す 500 エラーが表示されます (エラーが発生しているのは Web プロジェクトではなく、データ プロジェクトであることに注意してください)。outboundRules セクションを削除するとすぐに、サイトが再び機能し始めます。

sgen を使用してローカルで XmlSerializer を実際に生成しようとしましたが、次のエラーで失敗します。

したがって、OutboundRules には常に XmlSerializer が必要であると想定していますが、常にオンザフライで生成されます。この状況では、オンザフライでの生成が暗黙のうちに失敗するため、そのエラーが発生します。

では、まずシリアライザを機能させるにはどうすればよいでしょうか。第二に、なぜそれが必要なのですか？

ビジュアル スタジオ 2013。

リリースおよびデバッグ構成でビルドするソリューションがあります (すべてのプロジェクト構成がリリースおよびデバッグに適切に設定されています)。「ステージング」と呼ばれるカスタム構成を追加し、Web アプリのスタートアップ プロジェクトのみをこの構成に設定しました (他のすべての依存関係は引き続き [デバッグ] に設定されています)。

Webアプリを構築しようとすると...

SGEN : エラー : 要求された型の 1 つ以上を読み込めません。詳細については、LoaderExceptions プロパティを取得してください。

Web アプリのプロジェクト構成をデバッグに戻すと、機能します。Web アプリからステージング構成を削除し、デバッグ構成に基づいて再作成しましたが、まだエラーがあります。

私はこれに3時間立ち往生しているので、どんな助けも大歓迎です.

明確にするために、ステージング構成は、スタートアップ Web アプリがステージング構成を使用していることを除いて、デバッグ構成とまったく同じです。この構成は削除され、デバッグ構成に基づいて再作成されました。

プロジェクトの .csproj のターゲット (ビルド後) にsgen.exeコマンドを配置しました。コマンドはXmlSerializers.dllを生成し、プロジェクトはそれを期待どおりに使用します。

この問題は、プロジェクトを持っている人が.NET Reflectorを使用して、参照されているサード パーティ製アセンブリ を逆コンパイルおよびデバッグする場合に発生します。この時点で、プロジェクト sgen.exe コマンドを再コンパイルすると、アセンブリまたはいずれかを読み込めないため、エラーがスローされます。その依存関係、これは、外部参照アセンブリに「同じ名前の型」、「同じカスタム型を使用する 2 つのクラス」などの典型的な Sgen エラーがあるためです。サードパーティのアセンブリとして、私はそれを変更できません...そしてno use .NET Reflector はオプションではありません...解決策はありますか? またはそれを解決するためのリフレクターのオプション？または、Sgen がこのアセンブリの型を事前シリアル化しようとする理由を知っている人はいますか?

事前にありがとう...

よく説明されていない同様の問題がたくさんあるようです。

環境：

勝利7

VS2012 プロ

Windows SDK 7.0

私たちの環境では、x86 と x64 の 2 つのコード ベースを生成します。この特定のプロジェクトでは、 を生成し*.XMlSerializers.dllます。Generate Serialization Assembliesのビルドでの設定は ですAuto。

プロジェクトを x64 構成にコンパイルすると、SGEN エラー「アセンブリを正しくない形式でロードしようとしています... system.data.dll」が表示されます。詳細な調査により次の結果が得られたため、このエラーは完全に誤解を招く可能性があります。

procmonfromを使用しsysinternalsて SGEN をトレースしました

1. AnyCpuおよびx86 用にビルドすると、 procmonがトレースを表示します。使用中のsgenはC:\Program Files\Microsoft SDKs\Windows\v7.0\Bin(32 ビット sngen.exe)からのものです。
2. x64用にビルドする場合、トレースはなく、上記のエラーのみが表示されます

プロジェクト構成を設定してシリアライザーを作成し、x64 でアセンブリをコンパイルしました。次に、コマンドラインを試しました

3. -で SGEN を使用して成功しましたC:\Program Files\Microsoft SDKs\Windows\v7.0\Bin\x64(注意してください - これは 64 ビットの sgen.exe です)。
4. x64 アセンブリでの 32 ビット SGEN の実行に失敗しました。

これらの結果から結論が導き出されます。VS2012 がGenerate Serialization AssembliesをONに設定してプロジェクトをコンパイルすると( autoは特殊なケースです)、sgen.exeを見つけようとします。ただし、プロジェクト構成が x64 プラットフォーム用にビルドするように設定されている場合、x64 用にビルドされた適切なsgen.exeが見つかりません。

質問: Visual Studio が適切な SGEN を見つけられるように設定できるmsbuild構成またはレジストリ設定、またはその他の設定はありますか?

回避策、つまりビルド後のイベントとそれをオフにすることについては知っていますが、これは重要ではありません。

私は現在、XML スキーマを使用して C# クラスを生成し、C# クラスをコンパイルして sgen.exe でそれらを SGEN し、シリアル化可能な .dll を作成するコード生成ツールを開発しています。問題は、sgen.exe からシリアル化可能な dll を生成するのに時間がかかりすぎることです。私のプロジェクトには約 1400 のシリアル化可能なクラスが含まれている可能性があります。

sgen.exe は正常に完了し、有効な .dll を生成しますが、約 25 ～ 30 分かかります。これにより、このプロジェクトのテストは悪夢になります。これをスピードアップする方法はありますか？sgen.exe がプロセッサの 1 つのコアしか使用していないことがわかりますが、これは sgen.exe がマルチスレッド化できないためだと思います。これをスピードアップする方法はありますか？