Message: Internal limitation: too many fields.

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

re: Message: Internal limitation: too many fields.

Colin Desmond wrote:[color=blue]
> 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?[/color]

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.
[color=blue]
> 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?[/color]

Apparently not, according to the thread you cited.

-cd

re: Message: Internal limitation: too many fields.

"Colin Desmond" <ColinDesmond@discussions.microsoft.com> wrote[color=blue]
>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.
>[/color]
IIRC that's the number of _member fields per class_. You could easily
move some of these to other classes.
[color=blue]
> 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?
>[/color]
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