Blog Archives

How to Debug a Plugin in CRM 2011?

5 steps to Debug a plugin in CRM 2011

Step1. Register and deploy the plug-in assembly.
If there is another copy of the assembly at the same location and you cannot overwrite that copy because it is locked by Microsoft Dynamics CRM, you must restart the service process that was executing the plug-in.
Step2. Configure the debugger.
Attach the debugger to the process on the Microsoft Dynamics CRM server that will run your plug-in. Refer to the following table to identify the process.
Plug-in Registration Configuration
Service Process
asynchronous registered plug-ins (or custom workflow assemblies)
sandbox (isolation mode)

If there are multiple processes running the same executable file, for example multiple w3wp.exe processes, attach the debugger to all instances of the running executable process. Next, set one or more breakpoints in your plug-in code.

Step 3. Test the plug-in.
Run the Microsoft Dynamics CRM application, or other custom application that uses the SDK, and perform whatever action is required to cause the plug-in to execute. For example, if a plug-in is registered for an account creation event, create a new account.
Step 4. Debug your plug-in code.
Make any needed changes to your code so that it performs as you want. If the code is changed, compile the code into an assembly and repeat steps 1 through 4 in this procedure as necessary. However, if you change the plug-in assembly’s major or minor version numbers, you must unregister the earlier version of the assembly and register the new version.
Step 5. Register the plug-in in the database.
After the edit/compile/deploy/test/debug cycle for your plug-in has been completed, unregister the (on-disk) plug-in assembly and then reregister the plug-in in the Microsoft Dynamics CRM database.
**For CRM 2011 Training, please check out our CRM Training page. Please share |Like in Facebook if you feel like this page is useful.

Unable to upgrade the CRM 2011 Plugin/Custom workflow assembly?

Have you come across the following errors/scenarios while upgrading a plugin/custom workflow assembly?

1. Unable to upgrade the Plugin assebly
2. Unable to upgrade the Custom Workflow assembly

Here is the reason:

“You might have changed the Major and Minor version components in the assebly version in the dll file. In this case, the assembly should be unregistered and re register.”

You may refer the below section which states how the assembly versioning works:

Assembly Versioning in Plugin/Custom Workflow assembly

Plug-in assemblies can be versioned using a number format of defined in the file of the Microsoft Visual Studio 2010 project. Depending on what part of the assembly version number is changed in a newer solution, the following behavior applies when an existing solution is updated through import.

  • The build or revision assembly version number is changed.

    This is considered an in-place upgrade. The older version of the assembly is removed when the solution containing the updated assembly is imported. Any pre-existing steps from the older solution are automatically changed to refer to the newer version of the assembly.

  • The major or minor assembly version number, except for the build or revision numbers, is changed.

    When an updated solution containing the revised assembly is imported, the assembly is considered a completely different assembly than the previous version of that assembly in the existing solution. Plug-in registration steps in the existing solution will continue to refer to the previous version of the assembly. If you want existing plug-in registration steps for the previous assembly to point to the revised assembly, you will need to use the Plug-in Registration tool to manually change the step configuration to refer to the revised assembly type. This should be done before exporting the updated assembly into a solution for later import.

**For CRM 2011 Training, please check out our CRM Training page. Please share |Like in Facebook if you feel like this page is useful.