Tag Archives: MSDYNCRM

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.

Manually Repairing a Sitemap. Part 1

As I mentioned a couple of week ago, my upgrade from CRM 2013 to CRM 2015 did not go well. One of the issues is my SiteMap was totally broken and I had to replace it with the “default.”

The only problem was I wiped out the custom entries for my marketing package, Click Dimensions.

No problem, I thought, I’ll just add the solution back.  Except that did not work.  I ran into ghost SiteMap entries from a previously remove solution. This required a call to Microsoft Support to get them corrected.

Once corrected, I was successfully able to import the solution.  Except there were no custom SiteMap entries.

Only only solution in this case is to manually add them, which involves this process:

The Process

1. Create a new solution.

2. Add the SiteMap to the solution.

3. Export the solution as unmanaged.

4. Unzip the solution files.

5. Take the solution file from the package you are attempting to import and unzip it as well.

6. Open the customization.xml file from step 4 in an editor like Visual Studio or Notepad++.

7. Open the customization.xml file from step 5 in an editor like Visual Studio or Notepad++.

8. Copy the information from the step 7 SiteMap and paste it into the proper location within the step 6 SiteMap.

9. You will need to remove some XML attributes that are specific to the Solution Import process. Here is an example:

<Group Id="Extensions" ResourceId="Group_Extensions" ordinalvalue="5" solutionaction="Added" />

You need to remove the any reference to ordianvalue and solutionaction.

10. Save the step 6 customization.xml file.

11. Re-Zip the files from step 4.

12. Import the solution back into CRM.

13. Refresh your browser and see if the SiteMap changes worked.

Things to Know

I did not get into great detail about the SiteMap itself because you really have to understand how it is organized and all of the components that are involved. If you do not understand these things, you can damage the SiteMap and render your CRM system inaccessible.

Before you start anything like this, please know and understand what you are doing.  See the references below.

If all else fails, open a case with Microsoft.

References

Edit the site map

SiteMap XML reference

SnapShot! 3.7 for Dynamics CRM is Available

My Dynamics CRM documentation tool, SnapShot!, version 3.7 is now available.

This version includes the following enhancements and corrections:

  • Compatibility with Dynamics CRM 2015 Online Update 1
  • The Entity and Field reports now have the GUID for each which I have found very useful when troubleshooting solution import issues.
  • Organizations with a large amount of customization are now better handled and will not encounter issues when exporting entities with large numbers of fields.
  • Issues encountered (randomly) when working with Dynamics CRM organizations that where previously created using Dynamics CRM 4.0 or before, have been corrected.

Visit the SnapShot! product page for more information.