Debugging Plug-in
During plug-in development, developer would want to test his plug-in before putting in production server to make sure it works as designed. One way to do it is to have a development environment to test plug-in which is great. However, the turn around time between deploy-test-debug-build-deploy is very significant. It would be nice if we can test plug-in locally without deploying it on CRM server. The approach I am going to show is to execute plug-in in a small EXE container. Since IPluginExecutionContext is just interface, we can mock the context in our test container.
This sample shows you how to populate relevant input parameters and how to create CrmService behind context. You might need to add more implementation to TestContext to suite your need but this sample should be a foundation you can build on for example pre/post image or MetadataService.
Developer can use this approach for both debugging during developement or for writing unit test. It would enable ISV to write unit test and run it from test harness/framework such as one provided by TFS.
Even though mocking IPluginExecutionContext can emulate container that plug-in will execute in, it is only approximation. Other differences can still make running in production different from test context, for example:
- Security context. CRM runs plug-in in service account (usually network service). Test contain runs plug-in in currently logged in user context. Files/registries may be accessible from log in user but service account may not , and vice versa.
- HttpContext. Accessing HttpContext.Current is not recommended. If you need something that is available only HttpContext.Current, please let us know. Ideally, plug-in should be able to get everything from IPluginExecutionContext.
NOTE: Depending on currenlty logged in user, you may or may not be able to impersonate a particular user. Only AD user in PrivUserGroup can impersonate other user in CRM.
|