Do you fix or a restore a Confused CRM Database?

Very odd situation occurred recently and left the poor CRM database in a state of confusion.

it started yesterday when I was getting an invalidCastingException when a plugin was running.

Unexpected exception from plug-in (Execute):  System.InvalidCastException: Unable to cast object of type ‘Microsoft.Xrm.Sdk.Entity’ to type ‘ActivityParty’

I couldn’t fathom why I was getting this error because I could walk through the code in a console app, calling the same business logic/class. I could see the entities file and it had the ActivityParty included in it, what the heck was the problem

The error above was happening yesterday, I came in today thinking about the error and cause must be linked to the entities file because this is used when creating and using early bound classes.  If I refresh the entities.class it should work.

 

crmsvcutil.exe
 

I had been running the crmsvcutil.exe but I hadn’t noticed it had been erroring, instead of refreshing the entities.class.

So today I started looking at the

I started when I was trying to build the early bound entities.class, I was getting an error

 

Exiting program with exception: Mapping failed for Microsoft.Crm.Metadata.EntityMetadata property Attributes with exception Microsoft.Crm.CrmException: Mapping failed for Microsoft.Crm.Metadata.AttributeMetadata property Description with exception System.ArgumentException: An item with the same key has already been added.

The only previous time I have seen duplicate, same key error is when you try and import a solution with a field which was deleted and recreated as a different type.

This error returns very little from the internet (never a good sign) but the one article I found which seemed to make sense was from CRM MVP David Jennaway
user had upgraded, the upgrade process had somehow created two metadata fields of the same type. It has an interesting script to find duplicates

Nothing is working

Developers can sometimes only access CRM from the SDK they forget to check things on the CRM front end e.g. the CRM Web application.

I went into CRM and found I couldn’t publish any customizations and in fact all the plugins were not working.

We quickly reached the opinion a server reboot might fix the problems and restarted it with the reason (Hosks big problem)

unfortunately this did not resolve the problem and what we think happened was CRM let us add two fields with the same name.  There were some modifications to one of the entities in the afternoon, which we think is probably the culprit

CRM had now decided to lock up good and proper, we could export any solutions to try and edit the

What to do next

It was a DEV solution were unmanaged.  This means deleting the solution won’t do anything to the customizations. If they were managed solutions deleting them would also remove the customizations (and the dodgy double field) but it would also remove all the data (hmm it might take a while to create/import all that data)

We couldn’t import a solution over the top, wait I will rephrase that, we could but importing solutions are an additive, which means they only add things, they will not remove them.

CRM 2013 – Understanding Solutions and how they work

Restore or Fix (Stick or Twist)

Sometimes you have to make a decision to rollback to a previous database backup.  When you add the time it would take to investigate and fix the current CRM solution/database compared to rolling back to a daily backup from yesterday or maybe the day before.

In this calculation you also need to think about how many people are working on the project because during investigation it means other developers had to stop.  We think we might have known the cause but fixing it looked like tampering with the database directly.  This isn’t a great solution because we might just be kicking the problems down the road because we couldn’t be sure (if we worked out how to fix the problem) when fixing the problem we were creating more problems which we would find later.

Sometimes it’s better to lose one day of customizations versus weeks/months of potentially corrupt customizations

This is also highlights the importance of checking in your code changes into source control.  Most of the changes I have made during the last couple of days are all held in source control, so I just need to redeploy.

Changes to CRM customizations are a bit more tricky e.g.

  • Entity changes
  • fields
  • views

These can only really be backed up by exporting the solutions they are held in, on a daily basis, although they are of course also backed up in the database itself.  It is possible to export solutions programatically, so you could create an application which you could setup to a windows daily task (although I haven’t yet seen anyone do this)

The morale of the story is, make sure you put your changes in source control because the server could get corrupted or your own computer could crash or get lost and then you could be in real trouble

picture confused from here

picture wall from here
stick or twist picture

CRM 2011/2013 – System.InvalidCastException: Unable to cast object of type ‘Microsoft.Xrm.Sdk.Entity’ to type

I had an odd error today whilst developing and it turned out to be a very frustrating few hours.

I was writing a plugin which would work for Lead and Contact and because of this I was using a mixture of late binding and early binding.

The late binding was used because I was writing a plugin to fire on update and create of a lead/contact. It was working out the salutation. It was different entities but the same field names.

So I used Entity object and late binding to get the values of a 2 field, I was using these values to retrieve the data from another entity which was early bound.

My personal preference is to use early binding because I find the code is easier to read, it’s also a lot easier to  write because you can use intellisense to get the fields rather than looking at the exact field name.  The other benefit of early binding is you remove any syntax errors from run time and casting/conversion errors are found whilst compiling.

 

Casting error

It was working fine, my queryexpression was returning some records but when I tried to cast the records from Entity to my early bound entity I was getting

System.InvalidCastException: Unable to cast object of type ‘Microsoft.Xrm.Sdk.Entity’ to type…

Now this is a common problem people have had with early bound types

Usually to resolve the problem you need to add one of the lines below to say, yes – enable ProxyTypes for my CRMService (IOrganizationService)

_serviceProxy.ServiceConfiguration.CurrentServiceEndpoint.Behaviors.Add(new ProxyTypesBehavior());
_serviceProxy.EnableProxyTypes();

But looking at my code I could see I already had this

 

Duplicate Entities Reference

Then whilst building the project I was getting this error

Duplicate ‘Microsoft.Xrm.Sdk.Client.ProxyTypesAssemblyAttribute’ attribute

What the heck does this mean, more internet searching

This brought me to this page

and an answer from CRM MVP Gonzalo

Reference assemblies are not supported in CRM (at least officially) and they can always cause headaches, I strongly discourage them. What you can do is include the generated code from crmsvcutil.exe into each of your plugin assemblies and that should work. You can also include this line of code in your plugin assembly (which is included in the generated code):

It seems the problem was due to someone trying to reference Entities class from inside a dll and this doesn’t really work and a better solution is to add the entities class, so it’s included in the plugin dll (and you don’t need to go outside to another DLL to get the entities.class)

Visual Studio pointed me to this line with it’s error

[assembly: Microsoft.Xrm.Sdk.Client.ProxyTypesAssemblyAttribute()]

I then noticed I had two references to Entities (early binding file)

using Hosk.Dynamics.Crm..Entities;
using Microsoft.Xrm.Sdk.Query;
using Hosk.Dynamics.Crm..ContactLead.Entities;

 

Now things started to become clear, when I looked at the entities file before it didn’t have the entity I wanted so I regenerated the entities file using the CRM Developer toolkit.

The downside of using the CRM Developer toolkit to do this is it creates an entities file for all of them.  I did notice before there only seemed to be a small selection of the entities.

I then found there was a separate project with the crmsvcutil.exe, for those of you who don’t know what this is, it’s the command line tool Microsoft has created for creating the early bound Entities file.

I have used and written about this before

https://crmbusiness.wordpress.com/2011/01/29/crm-2011-simple-crmsvcutil-example-for-creating-early-bound-classes/

https://crmbusiness.wordpress.com/2011/02/24/crm-2011-how-to-add-crmsvcutil-to-the-external-tools-menu-in-visual-studio/

 

Only Create the Entities you need

The crmsvcutil.exe takes some config values which allows you to specify which entities you want to create early binding for.

You can pass some variables to the exe

<?xml version=”1.0″ encoding=”utf-8″ ?>

<configuration>
<appSettings>
<add key=”o” value=”Entities.cs“/>
<add key=”url” value=”http://<CRM Server url/>CRMORGNAME/XRMServices/2011/Organization.svc“/>
<add key=”namespace” value=”Hosk.Entities”/>
<add key=”codewriterfilter” value=”BasicFilteringService,CrmSvcUtilExtensions”/>
</appSettings>
</configuration>

 

Then a text file called EntitiesToBuild.txt and in this file were all the entities we wanted to build early bindings for.

This is great stuff, it’s efficient because it creates early bound data only need the early bound entities you use in the code.  Limiting the entities you create the early bound entities file will save you time creating/refreshing the entities file and reduce the size of plugin dll’s.

Missing References

I added in my entity, ran the crmsvcutil.exe but then suddenly I got loads of errors.  A previous developer had created the entities file but hadn’t updated the EntitiesToBuild so I was missing a bunch of entities which used early binding.

I added these entities in and then I got some error with fields missing.

One of the plugins was no longer being used and many of the fields it was using had been deleted.

 

Finally it compiled and I was up and running again, I had forgotten what I was actually doing.

 

Early Bound Generator

The solution for creating the early bound classes worked, there is now a tool which can do it for you, so you don’t have to spend any time using the crmsvcutil with the command line.

The tool is the Early Bound Generator and has a nice GUI interface for you, I have reviewed it on a previous blog/video

https://crmbusiness.wordpress.com/2014/05/13/crm-2013-tool-crm-early-bound-generator/

here is a link to the codeplex site

https://xrmearlyboundgenerator.codeplex.com/

 

The tool has been  improved since my initial review.  I will also proudly add the Hosk CRM blog is the link which brings the most traffic to the codeplex site and mentioning it here may even send a bit more traffic towards over that way, not to mention I love CRM tools.

If you want to see the other CRM tools I have reviewed click the link below

https://crmbusiness.wordpress.com/hosks-microsoft-dynamic-crm-development/crm-2013-tools/

 

Why should I care about this error

It’s true you probably won’t get the error in the same scenario as above but it’s useful to know about this casting error and the cause.

If you ever see errors about casting Microsoft.Xrm.Sdk.Entity type to a custom entity type then you know there is some problem with the entities file.

Often the problem is the entities file is not up to date/not the latest version as I discussed in the blog post below earlier this week

Error – the source file is different from when the module was built

So as soon as you see this error, you know it’s an early bound/Entities problem.