I registered one plugin assembly with two plugins written targeted to contact entity and registered in one of Dynamics CRM 2015 Online instances. It worked properly after adding steps into it. Here I am discussing the issue raised, an observation was done and the solution to the issue. But this only on a scenario for this issue to be raised and there can be many other scenarios to see this same issue.
Issue: After some time I wanted to add few more plug-ins to the same assembly, targeting some custom entity events and I updated the same registered plugin assembly with the newly build assembly. However, after adding steps to the relevant plugins and after triggering relevant events I got some errors from all the plugins I newly added. I checked the very first plugin events I registered in the same assembly and those functioned perfectly.
Error Message: All the errors showed the same error message “The plug-in type could not be found in the plug-in assembly:” in them.
Unhandled Exception: System.ServiceModel.FaultException`1[[Microsoft.Xrm.Sdk.OrganizationServiceFault, Microsoft.Xrm.Sdk, Version=188.8.131.52, Culture=neutral, PublicKeyToken=31bf3856ad364e35]]: System.ArgumentNullException: Value cannot be null.
Parameter name: TrackingId: 87e5f936-7499-4bc1-b649-f78fd4739016, Depth: 1, Message: SandboxAppDomainHelper.Execute: The plug-in type could not be found in the plug-in assembly: Continue reading "ISSUE: The plug-in type could not be found in the plug-in assembly"
Sales process is one of the main OOTB business processes in Dynamics CRM. During the sales process Opportunities can be created from Leads (Potential Customers) and opportunities contain opportunity products. From opportunities, quotes can be created, orders can be created from quotes and then invoices can be created from orders.
In this post let’s see how to generate invoice from opportunity using code and overcome issues when getting the OpportunityId.
CRM SDK provides few Methods to Generate Quotes, Orders and Invoices programmatically from Opportunity at any event. Following table shows the Requests and their descriptions that we can use to generate Quotes, Orders and Invoices from Opportunity.
Invoice can be created when the Opportunity closes as won and Plugin Continue reading “Generate Invoice from Opportunity when Closing as Won”
Plugins can be used to execute\perform a task in a event of changing a field of a record in an entity in CRM. Update message can be used in plugins when updating a field in an entity but how can we trigger an event when adding or removing a child record exists under a Many to Many relationship?
When Many to Many relationship exists and some task to be performed when adding records\removing records to\from parent\child entities, we can register a plugin which includes the task to be performed, using plugin registration tool to trigger the plugin at the right time.
Scenario: A system contains students and it captures mandatory subjects for each student. Meaning that one student may exist many subjects (Maths, Science etc…) and one Subject can have many Students according the relationship. Lets assume that both Student and Subject entities are custom entities with new prefix in it.
The task is that; whenever we add\remove a Subject from Student we should update a text field in Student.
Plugin : Continue reading “Capture Associate\Disassociate Events in Plugins”
Not like in most of the other developments, in Plugins developers have to debug the CRM plugin code at the time of running the application. Developers writing the plugin code inside the plugin and some times the logic can be write in a seperate assembly and from the plugin code it can be invoked. When writing the whole logic inside the plugin is little complex to test the plugin logic by debugging the plugin as it executes from the application itself in a given event such as create an entity, update or delete.
There are two ways of debugging a CRM plugin as follows,
 Attaching the debugger to the w3p.exe process
 Forcing the add-in to call the debugger
A plugin has written targeting Account entities as follows and a step has registered to be fired on Account entity’s Create step.
Continue reading “Debugging a Plug-in”
Auto numbering features are important in any business application to accomplish some business needs. Same in the CRM application and it needs additional customizations and plugin(or a custom workflow) to be implemented for the entity to statisfy auto numbering requirements. Jaimie Ji has a solution for this in CodePlex and this post is to demonstrate how to get use of Auto Numbering Solution in CRM. Advantage of the solution is that; developers dont need to write seperate plugins for each entity which needs auto numbering and it provides prefix, postfix, starting number and increment by features as well. Also it always open to change the configurations and no need any hard code values.
Unmanaged Solution (http://crm2011autonumber.codeplex.com/)
Auto Numbering Solution has a CRM solution and the solution contains one entity called “Counter” to save all the settings for all the counters. If there are two auto numbers in two different entities, just need only two records of this counter entity in the CRM application.
CRM.Plugin.SequenceGenerator is another component of the solution. If the solution doesnt contain the plugin, developers can get the source code from CodePlex, build it and can get the assembly registered in the CRM application manually.
There are some images as utilities to the Counter entity in the solution.
Source Code (http://crm2011autonumber.codeplex.com/SourceControl/list/changesets)
Source code contains the visual studio solution for the plugin. Developers can download the code, buil it and use the assembly for the registration. Plugin registration tool can be used to register the pluging in CRM application. The assembly can be attached to the CRM auto numbering solution and can be exported as a managed solution to be used in some other CRM projects.
Continue reading “CRM 2011 Autonumbering Solution”
Debugging CRM Plugins is no longer difficult with Plug-in Profiler. Follow the steps below and try to debug a CRM plugin in your environment.
1.Build the Plug-in Registration tool according to the instructions in its Readme file. The tool can be found in the Tools\PluginRegistration folder of the SDK download.
Current version of the SDK is 5.0.10
2.Run the Plug-in Registration tool.
Run the Visual Studio solution of plugin registration tool or after build the solution, Run the “PluginRegistration.exe” under “\tools\pluginregistration\bin\Debug\” folder
3.Connect to a Microsoft Dynamics CRM server and organization. For more information on connecting to a server and organization, refer to the SDK topic: Walkthrough: Register a Plug-in Using the Plug-in Registration Tool.
4.Register a plug-in and step on the Microsoft Dynamics CRM server. Keep a copy of the debug compiled plug-in assembly on the computer where you are running the tool.
Although Released or Debug assembly has been registered with the PluginRegistration tool, here it needs Debug Compiled vesion of the assembly to be debug using plugin profiler.
5.In the tool’s main window, select Install Profiler. You will now see a Plug-in Profiler node in the list.
Continue reading “Debug a CRM Plug-in using the Plug-in Profiler”
The 3 storage options are: Database, Disk and GAC. The main differences between these are:
Database: The assembly dll is stored in the database, rather than the file system. The major advantages are that the assembly need only be deployed once multiple CRM servers are available, and that no additional action is required to restore / redeploy the assembly either during disaster recovery, or if redeploying to an alternate server. This is the preferred option in a production environment
Disk: The assembly dll is placed in the \server\bin\assembly directory on each server. Have to ensure the dll is placed in the correct place on all CRM servers, so the deployment overhead is a little greater. Better to use this option in development environments as the developer can redeploy newer versions solely by file transfer, rather than reregistering. Also, if debugging, the assembly .pdb file needs to be placed in the same location; with this option it’s easy to ensure the dll and pdb are from the same build
GAC: The assembly is placed in the Global Assembly Cache on each CRM server, and again will have to do this. The GAC does allow multiple versions of an assembly, but CRM doesn’t, so don’t really gain anything by using the GAC.
According to my experience deploying the plugin assemblies to the Database is the best option as we can backup and restore the databases and minimizing assemblies deployments and other setting changes.