CRM 2011 plug-in tips and tricks (part 1) - Develop and Debug in Sandbox Isolation Mode

There are a lot of examples of writing CRM 2011 plug-ins in the SDK, but none of them really describe the process of testing, troubleshooting, and properly debugging you're plug-in code.  As a result I see a lot of developers wasting time and making guesses at the reasons for their plug-in errors. So in the following posts I will outline some of the gotchas and tricks I've learned so far while developing plug-ins for CRM 2011.

#1.  Develop and Debug in Sandbox Isolation Mode (its faster)

If you ever want your plug-ins to work on CRM Online then you need to make sure you're plug-ins work in sandbox isolation mode.  And you will be surprised to learn what works and doesnt work when in sandbox mode.  These are just a few of the things I've run into that don't work in sandboxed plug-ins

• Calling a web-service using IP address or localhost.
• Creating the WCF service proxy class by calling its constructor.
• CRM LINQ queries 
• Calling a web service using default credentials

The best way to avoid being surprised by any of these issues is to make sure you do all development in testing in Sandbox mode.  You don't want to be surprised when you deploy your plug-in to CRM Online and find out you're using some .NET function that isn't supported.

Also, it is now actually easier to debug plug-ins when they are sand-boxed. When registering a plug-in, you have three options of where the plug-in can be stored.

1. On Disk - The plug-in assembly is stored on the CRM server file system (in the Server\Bin\Assembly folder). 
2. Database - The plug-in assembly is actually uploaded to the CRM server and stored in the CRM database.
3. GAC - The plug-in is stored in the global assembly cache on the CRM server.