Message: Internal limitation: too many fields.

[Colin Desmond]

I have hit a problem where my .exe appears to have too many global variables
and functions
(http://forums.microsoft.com/MSDN/Sho...7548&SiteID=1). This
means my applicaiton dies during startup as the main .exe assembly cannot be
loaded. I understand that the number of fields is limited to ~65k.

As I don't really want to undertake a major restructuring of my code, is
there any way to increase this limit? If I do have to do restructuring
exercise, it would be useful to know how far over the limit I have gone so I
know how much to trim. Is there any way of establishing the number of fields
in an assembly?

Thanks

Colin

[Carl Daniel [VC++ MVP]]

Colin Desmond wrote:

I have hit a problem where my .exe appears to have too many global
variables and functions
(http://forums.microsoft.com/MSDN/Sho...7548&SiteID=1).
This means my applicaiton dies during startup as the main .exe
assembly cannot be loaded. I understand that the number of fields is
limited to ~65k.

As I don't really want to undertake a major restructuring of my code,
is there any way to increase this limit?
No. It's a hard limit of the CLR. You have no alternative but
re-structuring your code into more, smaller modules. Compiling less of the
code with /clr, or within #pragma unmanaged sections might help too, since
such code is not exposed to the CLR at all.
If I do have to do
restructuring exercise, it would be useful to know how far over the
limit I have gone so I know how much to trim. Is there any way of
establishing the number of fields in an assembly?

Apparently not, according to the thread you cited.

-cd

[Holger Grund]

"Colin Desmond" <Co**********@discussions.microsoft.com> wrote

I have hit a problem where my .exe appears to have too many global
variables
and functions
(http://forums.microsoft.com/MSDN/Sho...7548&SiteID=1).
This
means my applicaiton dies during startup as the main .exe assembly cannot
be
loaded. I understand that the number of fields is limited to ~65k.
IIRC that's the number of _member fields per class_. You could easily
move some of these to other classes.
As I don't really want to undertake a major restructuring of my code, is
there any way to increase this limit? If I do have to do restructuring
exercise, it would be useful to know how far over the limit I have gone so
I
know how much to trim. Is there any way of establishing the number of
fields
in an assembly?

A post-compilation/post-link tool could move these to other classes.
IIRC the fields are sorted by containing typedef at the physical level.
If you managed to define a helper class and convince the linker to
emit it as second typedef after <Module>, you could update its
FieldList.

Granted that's quite a bit of a hack and I'm not even certain
it works ...

You can easily determine the number of global fields with
ildasm /out /METADATA:RAW /METADATA:heaps

Just take a look at the second entry of the typedef table.

-hg