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.

You my find it on my Free Utilities page.

The actual roadmap document can be found here.

Looks like we're in for some exciting times this year!

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.

If you have not heard, Dynamics CRM 2011 will very shortly support browsers other than Internet Explorer.

I am absolutely unsure if this is a big deal for customers or not.  So, I thought I'd ask.

I've created a poll on my site that allows you to select which browsers you will be using. If you have some time, I'd appreciate the feedback.

You can also leave a comment on this post.

Thanks, Mitch

You use it like this:

string xmlPacket = HttpUtility.HtmlDecode(input);

This method is found inside of System.Web, which seems to require full trust to run properly.

Since I'm running in the sandbox, I can only use partial trust assemblies.

Thankfully, the System.Net assembly has: WebUtility.HtmlDecode, which works exactly the same AND doesn't cause us security issues.

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.

Attaching to Processes

Sandboxed plugins are run by Microsoft.Crm.Sandbox.WorkerProcess.exe so that is the process that you will need to attach to in order to debug your plugin.  If there are more than one, then attach to all of them.

If there are none active in memory, perform whatever process that activates your plugin and the Sandbox HostService will activate at least one. Then you can attach to them.

If you are running a sandboxed plugin with an asynchronous step, you will also need to attach to CrmAsyncService.exe since this process is involved as well. More on that in a minute.

Using the Debugger

The Sandbox HostService only allows the WorkerProcess to process for 30 seconds. If it runs longer, it is terminated. This is a real problem when you're trying to look at data within the debugger and your code and data disappears in front of your eyes.

Add a DWORD key called SandboxDebugPlugins with a value of 1 to the MSCRM registry to prevent the process from being abnormally terminated.

Asynchronous Plugin Steps

A very interesting factoid is that if you have an asynchronous step inside of the sandbox plug, the processing of the step is different:

The CrmAsyncService.exe process will run your asynchronous step as it would any other async process but since it is from a sandboxed plugin, it will actually hand your plugin to the Sandbox process for execution.

This is why you must attach to both the Microsoft.Crm.Sandbox.WorkerProcess.exe and CrmAsyncService.exe in order to get the Visual Studio debugger to launch.

More Information

See this topic in the CRM SDK for more information.

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.