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 the 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 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!

The story is almost identical for Windows Phone development where keeping your app size in check is even more critical. On this occasion the CRM team stepped up and produced a ready-to-use project. Of course, mobile development is not only about the size trimming but that’s a story for another day.