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
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.
Hosk's Dynamic Blog 