You will find it on the Free Solutions page.

Included in the zip file are:

• An unmanaged solution
• A managed solution
• Sample code ( below )

Usage:

Perform the following steps to add the solution to your system:

1. Import the solution into CRM. In the Settings area, you'll find a Plugin Settings link.

2. Add a record to specify a plugin configuration setting. There are three parameters:

• Plugin Name
• Setting Name
• Setting Value

As shown in the figure below:

In your plugin, you'll need to add a method to extract get your setting:

public static string GetPluginConfigSetting(IOrganizationService service, 

                       string pluginName, 

                       string pluginSettingName)
{
    var queryByAttribute = new QueryByAttribute("m3_pluginsetting");
    queryByAttribute.Attributes.AddRange(new [] { "m3_pluginname", "m3_settingname" } );
    queryByAttribute.Values.AddRange(new object[] { pluginName, pluginSettingName });
    queryByAttribute.ColumnSet = new ColumnSet();
    queryByAttribute.ColumnSet.AddColumn("m3_settings");

    var retrieved = service.RetrieveMultiple(queryByAttribute);

    if (retrieved.Entities.Count > 0)
    {
        return retrieved.Entities[0].Attributes["m3_settings"].ToString();
    }

    throw new InvalidPluginExecutionException(

              "Unable to retrieve configuration settings.");
}

This method is called like this:

UnsecureInformation = GetPluginConfigSetting(crmService, "MyPlugin",
                                            "ConnectionString");

Alternatives

The Adxstudio Productivity Pack for Dynamics CRM 2011 has a similar feature so that is an alternative if you need one.

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.

Each product has their own version and they are not compatible.

Also, once the VM is up and running in Virtual Server, you can't uninstall the Virtual PC Integration Services ( at least I've never been able to find a way ).

Note: There may be tools that do this, but I'm not aware of any. So if you know something I don't please put a comment on this article.

Finally, make sure you consolidate any snapshot images and do a clean reboot and final shutdown before you begin your move.

You'll be much happier in the long run.

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.

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.

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.

If you plan on writing anything that uses the CRM 2011 SDK, you may at some point run into the following error message:

The application terminated with an error.
Could not load file or assembly 'Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.

Solution:

You need to install the Windows Identity Foundation which contains a referenced assembly then add that assembly as a reference to your project.

Process is terminated due to StackOverflowException.

This was very odd because I had the ILMerge command running as part of a Post-Build process which had worked correctly all day.  Then it stopped.

The only change that was made to my machine was an update to Apple's iTunes software.  No idea if that is what caused it but that was all that changed.  And I even tried rebooting, without effect.

Finally, I found the answer here.

This made my Post-Build command look like this:

if $(ConfigurationName) == Release
"$(ProgramFiles)\Microsoft\Ilmerge\Ilmerge.exe"
/targetplatform:v4,"%ProgramFiles%\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0"
/keyfile:"$(ProjectDir)$(AssemblyOriginatorKeyFile)"
/out:"$(TargetDir)$(AssemblyName).Merged.dll"
"$(TargetDir)$(AssemblyName).dll"
"$(TargetDir)CRMAccelerators.Licensing.dll" 
/log:"$(AssemblyName).ILMerge.log

The command-line parameter /targetplatform was what fixed it.