This updated fixes some issues where the JavaScript would not be exported depending upon the solution you selected and the solution you chose to export. ( it was basically a design-flaw on my part. )

If you are running IFD using ADFS to access your CRM system, then you may be unable to connect to CRM. If you receive a 401 error, then please let me know.  I am currently working with Microsoft to determine a course of action around this issue.

Otherwise, if you find any issues, then please let me know.

1. Added 0 and 1 as supported Submit Options
2. Fixed issues with converting .AddOption to .addOption method.
3. Conversion alerts were added for the following JavaScript properties:

• .title
• .vAlign
• .contentEditable
• .innerText

1. Any .style property that is not either display or visible is now marked as a conversion issue. This is to help identify instances where people have created unsupported code which will probably not work within the CRM 2011 environment.
2. The use of document.all.mnuBar1 now produces a conversion alert.
3. Instances of the DOM element 'Notifications' will cause a conversion alert will be generated. This is a special CRM form element at the top of each data entry form that shows alerts to the user. For more information on using this technique, see this article.

You may download the new package here.

Normally, people access a form field using the following style of JavaScript:

crmForm.all.name

This is the normal and perfectly acceptable (and supported) method for referencing CRM form fields.

But, for various reasons, I've also seen fields reference using these crmForm methods:

crmForm.name
crmForm.elements["name"]
crmForm.all["name"]
crmForm["name"]

This is perfectly acceptable JavaScript and the CRM 4.0 object model had no objection to this practice, so all of these methods seemed to work.

In fact, accessing CRM form fields using the JavaScript document object using these methods worked as well:

document.all("name_c")
document.all["name"]
document.getElementById("name_c")

The real question is: Will these methods continue to work when the organization is upgraded to CRM 2011?

The answer is: If you have used standard and supported methods within your JavaScript, then yes, the code will be supported.

This means referencing all of your form fields using the standard access model:

crmForm.all.name

Other options may or may not work correctly. Your experience my vary depending on which of the above methods were used.

Fortunately, the CRM Migration Assistant converts all of these "unsupported" form field access types into fully-supported CRM 2011 code using Xrm.Page.getAttribute and Xrm.Page.getControl, depending on how the field was being used.

If you haven't already, download the trial version of the CRM Migration Assistant and convert some of your questionable JavaScript through the conversion process.

If you run into any conversion issues, send me a code sample so that I can update the conversion process.

Always, Always, Always export all of your customizations from the source environment.

You can always import only the items that you are working on. The Import Customizations page allows you to select the items being imported.

Using this technique gives CRM all of the information about your customizations and schema so it it needs some secret little part of something, it is available.

Sometimes it will miss data or other relevant information and while not producing an error, may not fully recreate the customizations as you defined them within the source environment.

I have seen this appear as lost icons, invalid relationship connections, and just plain strange stuff that takes hours to find and fix.

An Example:

Last year, I ran into such a situation where we could not Publish All Customizations.

It took me about 6 hours to find and fix but the problem was related to a custom entity that was, well, broken.  I had to manually insert a record into the database to fix it. ( and yes, that scared the crap out of me. )

It is my firm belief that this occurred because the person who installed the customizations only moved the four entities required from one organization to the other.

My initial solution was to export all customizations from the original source organization, import only those four entities into the development environment, then finish the remainder of the database cleanup manually.

This process had to be duplicated to the test and production organizations as well.

All in all, not a fun time and one that stretched my personal and professional expertise to the limit.

After you have installed the CRM SDK, navigate to the following folder:

sdk\samplecode\cs\helpercode

In that folder you will find, among other things, three files related to error codes, each in a different format. It appears that there are around 2,015 error codes.  Wow, that's a lot of documentation!

crmerrors.xlsx

Is a Microsoft Excel worksheet formatted like this:

errorcodes.cs

Is a C# class that has the error codes inside of a class that you can incorporate into your applications. The code starts off like this:

private static Hashtable ErrorMessages = new Hashtable();

static ErrorCodes()
{
    ErrorMessages.Add(InvalidAuth,
        "Organization Authentication does not match the current discovery service Role.");
    ErrorMessages.Add(CannotUpdateOrgDBOrgSettingWhenOffline,
        "Organization Settings stored in Organization Database cannot be set when offline.");
    ErrorMessages.Add(InvalidOrgDBOrgSetting,
        "Invalid Organization Setting passed in. Please check the datatype and pass in an appropriate value.");
    ErrorMessages.Add(UnknownInvalidTransformationParameterGeneric,
        "One or more input transformation parameter values are invalid: {0}.");
    ErrorMessages.Add(InvalidTransformationParameterOutsideRangeGeneric,
        "One or more input transformation parameter values are outside the permissible range: {0}.");

crmerrors.xml

The final version of the file is an XML which is formatted like this:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<crmerrors xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <crmerror>
    <ErrorId>
      80048516
    </ErrorId>
    <ManagedErrorName>
      InvalidAuth
    </ManagedErrorName>
    <ErrorMessage>
      Organization Authentication does not match the current discovery service Role.
    </ErrorMessage>
  </crmerror>
  <crmerror>
    <ErrorId>
      80048515
    </ErrorId>
    <ManagedErrorName>
      CannotUpdateOrgDBOrgSettingWhenOffline
    </ManagedErrorName>
    <ErrorMessage>
      Organization Settings stored in Organization Database cannot be set when offline.
    </ErrorMessage>
  </crmerror>

Regardless of how you use it, these files are a great resource for any CRM developer.

This update includes:

What is a Message?

If you are new to Dynamics CRM development, a Message word that is used to instruct CRM to do something. As far as I can tell, since the early versions of the CRM SDK used the SOAP protocol exclusively, and SOAP passes messages, the term message became the standard name for CRM internal processing options

If anyone has any other explanation, please let me know and I'll update the post.

What do you do with Messages?

Messages are what a plugin "listens for" to know when to activate and perform whatever job it was programmed to do.

A Message is associated with a Plugin Step ( internally called a SdkMessageProcessingStep ), which is a pointer that associates your plugin code to a Dynamics CRM internal action.

Inside the Plugin Registration Tool, you may see something like this:

As you can see, I have an assembly called ClassLibrary1, within that assembly I have a single plugin, SamplePlugin, and that plugin has two steps:

1. Create of a queueitem
2. Create of an email

Create is the Message.

How do I make it GO?

So, how do you, as a plugin developer, figure out what message you need to use to properly configure your plugin?

Well, for the most part, it's pretty simple: You select the CRM operation you are interested in intercepting then select Entity that will be associated with that Message.

Here is how the configuration looks within the Plugin Registration Tool:

But what if I don't know what message to use?

Excellent question, and the reason for my article.

The very fine folks in the Dynamics CRM documentation team have created for us, an Excel worksheet that lists all of the messages associated with a CRM Entity.

After you install the CRM SDK, you'll find the worksheet here:

sdk\tools\message-entity support for plug-ins.xlsx

And here is how it looks:

It lists the following information:

• Message Name
• Primary Entity
• Secondary Entity
• Message Availability
• Server or
• Both – for Client and Server
• Entity Supported Deployment
• Server or
• Both – for Client and Server

How do I use it?

Usually, I know what Entity I am going to work with so I start there and filter the Primary Entity based on that information.

Next, I try and locate the Message Name that I might need. Now this sounds simple, but in certain cases, it's really hard to determine what exact message you should connect with.

In that case, I will sometimes create steps that monitor each possible message, connect my debugger to IIS, then execute the CRM operation of interest so that I see what message is actually being passed through to my plugin.

You can find the message in the Execution Context's MessageName property.

Option 2

A second option is to look in the SDK help file itself for topics like:

Email (E-mail) Entity Messages and Methods

Where you will find information like this:

This should be the same (mostly) list of Messages found in the Excel file. Just remove the word "Request" from the end of the Message Name found in the SDK help file and you should have a match.

Conclusion

Well, that's about it for today. Hopefully this will help you in your plugin development efforts.

This means that if you are creating a solution, you only have to include the Entity component, not the Application Ribbon component.

You can download the update from the Free Utilities page:

http://blogs.infinite-x.net/free-utilities

See this post for more detail about the process.

If you do not add the SiteMap to your solution, and you've specified that custom entities be displayed within it, then CRM will not be instructed to modify the SiteMap to when the Solution is imported and your custom entity will not be displayed as you expect.