Testing CRM rollups and .NET versions

In this article I will talk about testing patches and how .NET versions can cause odd errors.

Rollups and CRM Version

I had a customer who was using CRM 2013 Service patch 1 and wanted to test their customizations still worked when CRM 2013 SP1 rollup 3 was applied.

Testing a new CRM service pack or rollup involves using a new server and CRM instance.

You can have many CRM organisations deployed on one CRM server but if you upgrade the CRM server it will effect all the CRM organisations and I don’t know any method to roll back rollups.

Why can’t you rollback CRM versions

To understand the question you need to think what happens (could happen) when you apply a rollup

  • Possible changes to the database tables
  • Update to CRM SDK
  • Depreciating certain functional in CRM SDK

Database changes

Microsoft might change the whole structure of the CRM database between service patches and rollups, which is one of the reasons Microsoft recommends you do not write any code/customizations/reports which run directly against the CRM database.  Microsoft provide filtered views and the CRM SDK for you to integrate the CRM database.

I think during the CRM 2013 update Microsoft used to have base and extension tables for each entity. e.g.

  • entitynameBase
  • entitynameExtensionBase

e.g.

  • accountBase
  • AccountExtensionBase

Here is some more information on the merging of tables, which explains how you can run the table merging as a separate job but you have to do it.

Run the base and extension table merge as a separate operation

I have written before about unsupported customizations before – Why you shouldn’t put unsupported customizations in Microsoft Dynamics CRM.  The primary reason you should avoid unsupported customizations is if you have to escalate an issue to Microsoft they offer limited support if you have unsupported customizations (because those customizations might be the cause of the behaviour/bug)

New functionality in CRM SDK and CRM

Usually (but not always)

  • Roll ups contains fixes
  • Service packs contain fixes and new functionality

New functionality doesn’t usually break anything but sometimes existing functionality might change.

The key point is the CRM SDK will have changed,

Old CRM SDK functionality depreciated

With one hand Microsoft giveth new functionality and the other hand they take functionality away (depreciate).

You should always read the What’s new for a new release of CRM – Why you should read the What’s new for developers because it lists not only the new functionality but includes what’s being depreciated in Javascript and CRM SDK.

Applied patches but stuff not working

I applied the rollup to CRM 2013 SP 1 rollup 3 but when I tried to test CRM, I noticed I was getting unusual errors.  The core functionality of CRM was working but I was getting errors when the plugins triggered calls to WCF web services.  Below is the error

The Web Service plug-in failed in OrganizationId: 3666c2e6-04f4-e411-80c9-000c292122be; SdkMessageProcessingStepId: 2ccabb1b-ea3e-db11-86a7-000a3a5473e8; EntityName: incident; Stage: 30; MessageName: Create; AssemblyName:
Inner Exception: System.TypeLoadException: Could not load type ‘System.Runtime.CompilerServices.ExtensionAttribute’ from assembly ‘mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089′.
at System.ModuleHandle.ResolveType(RuntimeModule module, Int32 typeToken, IntPtr* typeInstArgs, Int32 typeInstCount, IntPtr* methodInstArgs, Int32 methodInstCount, ObjectHandleOnStack type)
at System.ModuleHandle.ResolveTypeHandleInternal(RuntimeModule module, Int32 typeToken, RuntimeTypeHandle[] typeInstantiationContext, RuntimeTypeHandle[] methodInstantiationContext)

To find this error I had to turn on tracing and look into the event logs because CRM was not giving much information.

I have highlighted the key part of the error.

This article was useful

Could not load type ‘System.Runtime.CompilerServices.ExtensionAttribute’ from assembly ‘mscorlib

This seemed a classic DLL type error, this usually occur when you there are differences between .NET versions or DLL’s deployed.

In this particular scenario I could compare the .NET version installed on the working CRM environment and the .NET version and other DLL’s in the new upgraded environment.

So I needed to check the .NET version, Microsoft has a great page on this

How to: Determine Which .NET Framework Versions Are Installed

Be careful because you have to read it carefully.  I was checking the .NET versions in regedit (full instructions in the link above) and the folder said v4.  I was expecting a 4.5 folder, so I assumed it was version 4.

Its a better to know facts rather than making assumptions particularly when trying to find a problem.  In the example above I assumed the .NET versions where the same, which meant I then wasted time investigating other parts of the server and DLL’s looking for potential problems.

If I had read the article more carefully  it more carefully I would have noticed this very important section

The value of the Release DWORD indicates which version of the .NET Framework is installed.

 

The folder will be v4 but if this has been updated it will have a new Release registry value and the number in this registry settings tells you what version of .NET is installed

.NET versions

 

I found there was a DWORD value in the working CRM Server which indicates I had 4.5.1 installed

378675 .NET Framework 4.5.1 installed with Windows 8.1 or Windows Server 2012 R2

I checked on the server I was updating CRM 2013 SP 1 to rollup 3 and it only had .NET framework 4

What was happening was the web services were compiled with .NET 4.5 but when they tried to run on the new server it couldn’t find the correct dll versions, this caused the odd errors.

What I learnt

Don’t make assumptions – Know don’t assume.

If web services are not working check the .NET versions and look for the secret DWORD registry setting Release.

 

Advertisement

CRM 2015 – CRM developers should think in Entities

The humble Entity is one of core building blocks of CRM and CRM development.

  • CRM developers need to view the world as entities
  • You need to translate users work items to entities
  • Understand out of the box entities and custom entities

When CRM developers look at things they should see things in entities like the matrix picture.

When a customer tells you the requirements you should be thinking about it in entities

You are an entity called CRM Developer!

What is an Entity

Entities do a lot in CRM, to understand what they are and what they do I think it helps to view them in different ways

Customer

Entities are used to model the business data of the customer to accompany the out of the box entities which exist in the default CRM system (account, task, contact, business unit)

CRM Database point of view

  • Every entity in CRM is a table in the CRM database.
  • Every field on an entity is a column on the entity table.

CRM Dev point of view

Most entities have at least one form in CRM.

Customizations are organised (to some extent around entities) in your solutions

Task

CRM Developer Plugins

Plugins are triggered by actions on Entities (you can add multiple triggers on a plugin).  The messages (read actions on an entity) aer

  • Create
  • Update
  • Delete
  • Retrieve
  • Retrieve Multiple
  • Assign
  • Share
  • Associate
  • Dissociate
  • Set State

Entity Status

Entities have a status and status reason.  These values can be used to drive the entity through a process/life cycle.  To learn more about Status and Status reason read the blogs below

CRM 2013 – Understanding Status and Status Reason – think before deleting them

CRM 2015 – how to find Statecode value

Security

Security roles set access rights on entities – Create, Read, Write, Delete, Append, Append To, Assign, Share.

Entities can be owned by users/teams and these provide access levels such as none, user, business unit, child business unit, organisational.

security

Start with the CRM SDK

When learning about topics in CRM it’s good policy to start with the CRM SDK and find the truth about entities, find out what properties and methods entities have.  When I use the term CRM SDK I mean the CRM SDK documentation

Development for Microsoft Dynamics CRM Online and on-premises (CRM SDK)

You could also look at the CRM Developer Website, which I wrote a blog about recently

CRM Developer Centre gets updated and it looks good

Entity

Microsoft.Xrm.Sdk.Entity

What properties/members do you get with the Entity

Entity Properties

The Entity has a number of properties but here are the keys ones

Attributes

The attributes parameter holds a collection of all the fields in an Entity.  The atrributes collection works by holding fields which have a value.  If a field is null it isn’t included in the attributes collection (when you call from plugins).

You often need to check for a value in the Attributes collection using the contains method

entity.Attributes.Contains(“name”);

This will create lots of if statements with contains, if true retrieve the attribute type code.  You can work around this by using Entity.GetAttributeValue which will get the value if the field exists in the Attributes collection or return the default value for simple variables or null for complex variables.  Read more about it using the link below

CRM 2013 – using Entity.GetAttributeValue instead of Entity.Contains

LogicalName
Each Entity has it’s own individual name stored as a string.  The logical name is useful because sometimes in the code you will need to know what type of entity it is e.g.

task, account, phonecall, contact.

The LogicalName can be useful if you have plugin code which is triggered on a number of different entities.

Id

The all important Id of the entity record.  This holds the Guid.  This is important because when you retrieve any information you can use this ID to retrieve the individual Entity record and ask for particular fields of interest.

EntityState

Gets the state of the entity, useful

Entity Abstraction and Early binding

Good practise for CRM developers is to use Early binding which will create an Entities file and allow you to create Account, Contact, Task records.

Early binding strongly types the field values for an entity.  These values are the same fields you would find in the attributes collection on the Entity object.

  • What are the benefits of early binding
  • Readability
  • moving type errors into compile time and not run time (e.g. compile time = developers, runtime = testing or users)
  • reduce syntax errors

The easy way to make your Entities file is to use the CRM Early bound generator

CRM 2013 Tool – CRM Early Bound Generator

Whilst you are there don’t forget to make your optionset enums

CRM 2013 – Create Enumerations for option sets

What has the Entity got to do with Abstraction?

When you are using early bound classes in your CRM code you are then extending Entity object with the new early bound classes

Entity –> Account, Contact, Task, etc

Using Entity can be useful when creating common functions because all your early bound classes inherit from Entity.

The code below checks the entity (which is an Entity object) to check the name.  The code in the example could be either a Task or PhoneCall.  The Complete activity either sets a task to completed or a phonecall to made.


            if (entity.LogicalName.Equals(Task.EntityLogicalName))
            {
                CompleteActivity(activity.ToEntity<Task>());
            }
            else if (entity.LogicalName.Equals(PhoneCall.EntityLogicalName))
            {
                CompleteActivity(activity.ToEntity<PhoneCall>());
            }

It’s useful to remember all early bound entities inherit from Entity.

EntityReference – Entity’s little brother

The EntityReference object in CRM is a lookup to an Entity object.  An EntityReference has LogicalName and Id (guid) of the entity.

When ever you see a lookup in a CRM form you know this is an EntityReference with just enough detail for you to retrieve the Entity object.

There is a good code tip is you can get an Entity Reference from an Entity object

Hosk CRM Dev Tip – Get EntityReference from Entity

EntityReference entRef = entity.ToEntityReference();

When creating new lookups on your forms, it’s best practise to put ID on the end of the field name, so CRM developers can easily find the lookups

Hosk CRM Dev Tip – add ID suffix to lookup fields

 

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