Check out the latest features available in Dynamics 365 for Customer Engagement, including LinkedIn Connect, Voice of the Customer and Universal Resource Scheduling.
Dynamics 365 2019 release wave 2 plan Discover the latest updates to Dynamics 365.Release Plan | Weekly Deployment Notes
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants.Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements.
ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Talent TechTalks
Hello,We are using CRM 2011 version with roll up 18. We have introduced a new class in the existing plugin assembly. It works well in unmanaged solution dev environment. When we import it on test environment, it fails with the error "Unable to load plugin type: xxx (new plugin class)". Workaround to this issue we found is to import the solution twice. In the first import, we do not activate SDK processing step by keeping the checkbox unchecked. In the second import of the same solution, we enable the checkbox.This is a legacy environment and we did not see this issue earlier when a new class is added in the plugin assembly. Recently there is a change in the CRM build process. Earlier we used to get managed build manually from dev environment using export option and used to import it on test environment. Now we are using solution packager approach to get the build so that we are not dependent on the machine. The issue that we are facing is only with the build we get from solution packager. If we import the managed build from dev machine, we do not see this issue. So something could be missing in solution packager. Can you give any pointers to resolve this issue?
There are few reasons why it could be failing, please see below
When your plugin code is built by the build process to get the DLL, it may not be using correct target platform or it may not be signing the DLL properly. So I would use something like the Dot Peek tool to compare the two DLLs. You could also compare the DLL properties in Windows Explorer You can extract the DLLs from solution file by unzipping the solution file, the DLL should be in plugin assemblies folder.
Get the solution created by the Build Process and also export the solution manually and unzip both solutions and copy the DLL from manual export to the build process created one and then zip and import that solution and see if you are still getting the error.
I think a possible explanation for it not failing is that in the first import the DLL check failed but the DLL will be saved to DB and the second time its not doing the same validation making your second import to go through successfully.
Business Applications communities