Upgrading an MSCRM 4.0 implementation to MSCRM 2011, we encountered a few issues regarding our custom plugins.

The upgrade actually worked fine, and our plugins continued to work in the new 2011 environment.

However, we encountered issues when trying to make changes to those legacy plugins - we were unable to update a plugin using the Plugin Registration Tool, and we also couldn't debug a plugin.

Here's what we did to get around these two problems:

Updating an MSCRM 4.0 plugin within MSCRM 2011

AccountPlugin.dll was written using Visual Studio 2008 and registered into a CRM 4.0 organisation. This organisation was then upgraded to CRM 2011.
We then had to make some changes to the dll. However, when trying to update the existing assembly using the Plugin Registration Tool, we received the error:

Plug-in assembly does not contain the required types or assembly content cannot be updated.

To resolve this, we had to un-register the existing assembly (and all its steps/images) using the Plugin Registration Tool. We were then able to re-register it as a new assembly (and had to re-configure the steps/images).

Debugging a MSCRM 4.0 plugin within MSCRM 2011

Once we had registered our updated version of AccountPlugin.dll, we wanted to debug it. So we loaded up the code in VS 2008, and attached to the w3wp.exe on the server.
Although our new plugin worked, we couldn't get it to hit any breakpoints, instead getting the dreaded "the breakpoint will not currently be hit. No symbols have been loaded for this document" problem.

To resolve this, we converted our VS2008 plugin project to a VS2010 plugin project.
When we attached that to w3wp.exe, we were able to hit our breakpoints and debug our code.


 
When running the Microsoft CRM 3.0 Redeployment Wizard on our new CRM Application/Web Server, we encountered the following error:

"An error occurred when Microsoft CRM data was being imported to Active Directory. The import failed."

We were running the wizard using a domain administrator account.

To resolve this, we instead ran the Redeployment Wizard on the CRM SQL Server. 



 
Picture
If you ever find the Dynamics CRM 2011 Explorer / Tools options missing from within Visual Studio 2010 ....

... check prerequisites are installed:-

1. Visual Studio 2010 SP1
2. Silverlight 4
3. Windows Identity Foundation
4. CRM Developer Tools (found within the CRM SDK, Tools folder)

Then check that the following is mentioned in your solution file (if you open the .sln file in a text editor):

Save and reload the solution in Visual Studio 2010 - everything should now be back!
 

Having backed up a CRM 4.0 Organisation database, and restored it into a CRM 2011 deployment, we attempted to use the "Import Organisation" feature of CRM Deployment Manager to import and upgrade the database.

Stepping through the "Import Organisation" wizard, we got to the "Map users" screen, where we expected to map the Active Directory users from the source deployment to equivalent users within this one. 

At this point, the  import wizard just hung. We waited a few days....still nothing, it was stuck on the same screen.

The install log, crm50dmsnapin.txt, revealed this error:

Exception occurred while mapping usersMicrosoft.Crm.CrmArgumentException: Expected non-empty string. ---> System.ArgumentException: Expected non-empty string.
Parameter name: domainAndAccount


To fix this, we ran the following SQL against the Organisation database we were trying to import:

update systemuserbase
set DomainName = 'domain\user'
where isNull(DomainName, '') = ''




 
We recently came across a cryptic error when trying to deploy a plugin to a CRM solution using the Visual Studio 2010 Solution Template for Dynamcis CRM 2011. The error was:

Error registering plugins and/or workflows. The resource string "ErrorSerializingRegFile" for the "RegisterPlugin" task cannot be found. Confirm that the resource name "ErrorSerializingRegFile" is correctly spelled, and the resource exists in the task's assembly.

Having created the solution, written a couple of plugins, and checked everything in to TFS, we tried to "Deploy":

The solution......check out the file "RegisterFile.crmregister" from the CrmPackage project, so the deployment process can write to it, obviously.