9

いくつかの新しい UI をマネージド/C# ランドに移行するために、最近、大規模なレガシー プロジェクトで共通言語ランタイム サポート (/clr) を有効にしました。全体的なソリューション。このプロジェクトはアプリケーションのコアであり、生成されたマネージ UI コードを駆動します (したがって、相互運用のために clr サポートを有効にする必要があります)。

大量の小さなエラーと警告を修正した後、最終的にアプリケーションをコンパイルすることができました..しかし、アプリケーションを実行すると EETypeLoadException が発生し、デバッグできなくなります...

掘り下げてみると、原因は「System.TypeLoadException: 内部制限: フィールドが多すぎます」であることがわかりました。これはコンパイルの最後に発生します。次に、アセンブリを2つ以上のdllに分割することを提案するこのリンクを見つけました。ただし、これは私の場合は不可能です。レガシー コードは基本的に変更されないという制限があるためです。

誰でも他の可能な解決策を提案できますか? 私は本当にここで行き止まりです。

4

3 に答える 3

14

[C/C++ コード生成] の下の [文字列プーリングを有効にする] オプションがオンになっていることを確認します。

通常、これでこの問題は修正されます。Excel スプレッドシートの 64k 制限などの MS 制限。これだけが、アセンブリに表示されるシンボルの数に影響を与えます。

于 2008-08-18T16:21:39.380 に答える
3

私はこれを非常に大規模な混合モード（C＃/ C ++）アプリケーションで3回（3x）実行しましたが、上記の修正を一度実行すると、エラーが発生することはありません。

いいえ、どちらかといえば、これにより実行時の実行がわずかに速くなるはずです（ただし、測定できるものはありません）。

しかし、私はそれがいくぶん一時的なものであることに同意します。シンボルの内部制限は以前は問題ではありませんでした。問題があった場合、その制限ははるかに高くなりました。次に、MSはローダーコードの一部を変更しました。私はMSDNにアクセスし、それについて怒鳴りましたが、「ばか者だけが1つのアセンブリにその数のシンボルを入れるだろう」と不確かな言葉で言われませんでした。

（これが、MSDNに参加しなくなった理由の1つです。）

まあ、私を愚かに着色しますが、ローダーが10,001個のシンボルが1つ多すぎると判断したという事実を回避するために、アプリケーションの物理構造を変更して衛星DLLに分割する必要はないと思います。

また、ご指摘のとおり、アセンブリ/サテライトDLLの構造や、それらに含まれる依存関係の種類を制御できないことがよくあります。

しかし、いずれにせよ、このエラーが再び発生することはないと思います。

于 2008-08-18T17:33:24.743 に答える
3

プロジェクト全体で/clrをオンにする必要がありますか？代わりに、選択した少数のファイルに対してのみオンにし、マネージコードを含める方法に細心の注意を払うことができますか？私は大規模なC++/ MFCアプリケーションを使用していますが、マネージC++を使用するのは非常に難しいことがわかりました。私はC＃と.NETが大好きですが、マネージC++は頭痛の種に過ぎません。私たちの問題のほとんどは.NET1.0/1.1で発生しました...多分今は状況が良くなっています。

于 2008-08-18T17:40:27.847 に答える