I’ve been hit with this error during my development and I thought it was the resources so I trimmed this down and still present so I am assuming it is one of the other classes, possibly the main one.
How can we know what has causes this error? It’s a totally useless error as it tells you nothing about what failed.
1>MMP : error MMP0000: CLR_E_OUT_OF_RANGE
I have even done some work to move a lot of the code into a couple of separate classes but I still get this error.
@ Dave McLaughlin - i think your dll (library) is to big
I can’t see any DLL as part of the build?
The exe is 624KB and the resources are 519KB but this is still within the 1.4M of the G400.
I really need a G400 with more FLASH storage as I still have a heap of features to add to this system 
What he said!! 
Actually, I have no idea what that is and how to build and configure for it. Do you have a link to this?
Cheers.
So you have all your code into the application? What if you create a library and move some code from the main app. to the lib?
@ Dave McLaughlin - I believe the limit on an assembly is around 800k.
I dropped out the uCloudy and Azure for the time being as it is tot yet required for this current release and now it builds and runs again.
Phew as I have a demo on Thursday and just doing some final tweaking and debugging.
@ leforban - Thanks. I understand the failure now but I wish it would tell you which module has exceeded the allowed size.
I’ve spent all day moving code into additional classes and the main code is now much smaller but I still get this dreaded error at times and it bugs me to not know which file is causing the build error.
There is nothing in the /bin/debug/be directory other than the exe and pdb files. (I did a clean before I rebuilt it)
I just wish there was a log file of the build process so I could check but I can’t find anything.
Have you tried compiling with the log file verbosity set to ‘Diagnostic’ (the highest level)? That might tease out more information. Tools->Options, Projects and Solutions, Build and Run, and then set “MSBuild project build output verbosity” to “Diagnostic”
If that fails, I think the source for the tool that is generating this message is in the NETMF source tree. One could run it in the debugger and/or add additional log statements to get it to output exactly what it is upset about.
It seems that you can also check all pe file sizes. They should not be greater than 6XkB.
That doesn’t appear to be the case. The Glide.pe file alone is 392KB in size.
What this has taught me is to try and break up the code into different projects, especially when I can break it into separate classes. I move a few of the classes that handle sensor data, modem etc into there own project and the include them and add events to pass data to and from each of them. A days work so not too much overhead to change it all.