Tag Archives: MSDYNCRM

This week’s free webinar: Contracting, Outsourcing, and Partnering on your Dynamics CRM Projects

Hi Everyone,

Just wanted to remind you of next week’s free webinar.

In this webinar we will discuss the some general principles to keep in mind when working with contractors, outsourcers, and partners when you are implementing or customizing Dynamics CRM.

Wed, Jul 21, 2015 11:00 AM – 12:00 PM CDT       Register Now

 

Thanks,  Mitch

July’s Free Dynamics CRM Webinars

Here are the webinars available this month:

Dynamics CRM JavaScript Debugging Basics

We will discuss the basics of debugging your Dynamics CRM JavaScript should you encounter issues with your code.

Wed, Jul 7, 2015 11:00 AM – 12:00 PM CDT       Register Now

 

Contracting, Outsourcing, and Partnering on your Dynamics CRM Projects

In this webinar we will discuss the some general principles to keep in mind when working with contractors, outsourcers, and partners when you are implementing or customizing Dynamics CRM

Wed, Jul 21, 2015 11:00 AM – 12:00 PM CDT       Register Now

Dynamics CRM JavaScript Development Workshop is this week

 

Hi Everyone,

If you are interested in Dynamics CRM JavaScript development then please consider attending my workshop this coming Thursday and Friday.

This is an extremely hands-on workshop with tons of labs and as part of your experience, you’ll receive some goodies from my toolbox which is the same code that I use to help develop solutions for my customers.

To learn more or to register, please visit the information page.

Thanks, Mitch

Dynamics CRM 2015 Upgrade Error: Invalid column name 'EntityName'

 

I was upgrading a Dynamics CRM 2011 system last week and ran into an issue when attempting to import a solution that contained my Entity, Form, and JavaScript changes.

Invalid column name 'EntityName'

After looking around and finally asking for help from my fellow MVPs, Joel Lindstrom suggested the CRM community forum thread:

CRM 2015: Generic SQL error – Invalid column name 'EntityName'.

Which pointed to this thread as well:

CRM 2015 – Error after update 0.1

Root Cause

It turns out that the .01 update was “possibly” partially applied to the organization that I was attempting to upgrade. That first forum thread started off discussing the importation of a solution, which was my issue, but also mentioned that the available upgrade for the organization was available, but could not be applied.  The options seemed to be:

  1. Wait for the .02 release, which fixes the problem.
  2. Call Microsoft and ask for the hotfix.
  3. Run a very scary set of manual steps to correct the issue.

Solution

The solution to the issue is the modification of an XML file that ships with the Dynamics CRM software and the manual creation of some databases indexes.

I performed these very scary set of steps, successfully updated the organization database, and then was able to successfully import my solution.

Final Thoughts

I encountered the error performing a trial-run of the upgrade process on Friday.  When I performed the actual upgrade process itself, on Saturday, I did not encounter the issue at all.  Looking at the organization database within the Deployment Manager, I see that the second organization import upgraded the database to 7.0.1.xxxx as expected.

I have no idea what would cause it to fail one time and succeed the other.

Source code recovery tip: Was this written in c# or VB.NET?

Every now and again I run into the unfortunate circumstance where someone has lost the source code to a Dynamics CRM plugin (or something similar).

When you encounter this type of situation your only hope is to decompile the source using the plugin assembly’s DLL file and spend a good deal of time modifying the source code to get close to what the original author wrote.

Today my tool of choice is JustDecompile from the fine folks at Telerik.

Decompilation is not an exact science simply because the code the compiler ended up generating is not exactly like the code the author wrote. Most of the time this is caused by optimizations that the compiler has inserted which replace the original author’s code with code that it thinks is “better” or in some cases, just because.

So when reviewing a decompilation, it is sometimes hard to make a determination if what you see is compiler-generated or user-generated, especially when it is not your code. And I should note that I have seen a lot of code written by people whose main job was not that of a developer, who grabbed some code out of the Dynamics CRM SDK or off of the Internet to solve a problem, without really knowing what they were doing.

So when you look at the decompiled code, you are always asking: did they write it this way, or is this the way it was compiled?

Today I ran into something quite different.

First off, the using statements look very strange:

image

And some of the comparison operations used methods that I had never seen before:

image

Which is in the Microsoft.VisualBasic.CompilerServices namespace. 

Very odd.  Why would a developer writing C# use Visual Basic.NET assemblies?

The answer is: They would not.  This code was originally written in VB.NET, not C#.

So I am still going to use the C# decompilation code, but knowing that this was originally written in VB.NET helps me understand a little bit better some of the code that I am seeing.

Just another note to put into your book somewhere.

Dynamics CRM Upgrade Blocker: Orphan Plugin Step Image records

Last week I was working with another Microsoft partner who was upgrading a customer’s Dynamics CRM from 2011 to 2015 when they ran into the following error moving to Dynamics CRM 2013 (which you must do, to get to 2015):

image

Note: SdkMessageProcessingStep is the internal name for a plugin step, as configured using the Plugin Registration Tool.

So we ran the following script to see if we could not locate the offending SDK Message Processing Step.

SELECT 
 SdkMessageIdName,
 Name,
 EventHandlerName,
 SdkMessageProcessingStepId
FROM
 SdkMessageProcessingStep
WHERE
 SdkMessageProcessingStepId = 'd987ac98-8b85-dd11-b48e-001143ec27a2'

And we got nothing.

This is very strange so I started looking around for anything else that could cause such and error – and I actually found it.

Root Cause

The issue was actually on a separate tabled called: SdkMessageProcessingStepImage, which stores the Pre or Post Image configuration for a specific plugin step.

This CRM system was originally v4.0 and somewhere in the upgrade to CRM 2011 a plugin step was removed from the system and the Plugin Registration Tool did not remove the associated Plugin Step Image, so these records remained in the database, unused and unnoticed until the upgrade process tried to modify them.

The actual error message is displayed because the SdkMessageProcessingStepImage is referencing the SdkMessageProcessingStep, which doesn’t exist-just like the error says.

Correcting the Issue

To verify this is indeed the problem, we ran this script:

SELECT 
  *
FROM
  SdkMessageProcessingStepImage 

WHERE
 SdkMessageProcessingStepId = 'd987ac98-8b85-dd11-b48e-001143ec27a2'

This will produce records if you actually have orphan Plugin Step Images.

Your next step is to remove those records from the database using a SQL command.  Kind of scary, but they are not being used anyway.

Conclusion

I have seen this type of error message a number of times so it does happen occasionally, but not all that frequently.  My theory is that a specific version of the Plugin Registration Tool, probably for CRM 4.0, was responsible for this issue and it was correctly in later versions of the tool.

I think that I need to add this as an upgrade check to my SnapShot! documentation tool.