Tip #368: Keep your early bound classes lean
The convenience of early bound classes often overshadows the side-effects of using those. It is, indeed, very easy to write:
CrmSvcUtil.exe /url:https://myorg.api.crm.dynamics.com/XRMServices/2011/Organization.svc
/out:GeneratedCode.cs /username:"myname@live.com" /password:"myp@ssword!"
then add generated file to the project and use syntax-checked
a.accountname = "Acme Inc"
instead of a["acountname"] = "Acme Inc"
(see what I’ve done here to demonstrate the usefulness of early-bound classes?)
This approach is acceptable if you are writing a Windows app or a command line utiltiy, less desirable if you are working on a portal code and is definitely a Spießrutenlaufen-generating behavior if your responsibility is a plugin. Why? Because the line above will generate over 6MB in raw C# code which will compile to something like 2.8MB assembly. This size maybe OK for a utility or even a web site but dragging all this code into a plugin assembly is definitely not a good idea, especially if you only need a handful of entities (which is usually the case for plugins).
CRM SDK does provide some paltry information how to control generation process but Eric Pool did the legwork on your behalf 4 years ago. Just follow the article and save both the time and megabytes.
The end result? If you only ever need an account entity, restricting class generation to that entity only generates nice and tidy 77KB source file which compiles into a puny 45KB assembly. Now that we can load into a plugin!
*This post is locked for comments