Search This Blog

Tuesday, November 17, 2009

Tools Update : New connection control

Hi everybody,

Following a user request, I added a new connection control in all my tools, which allows to save and load connections configuration from/to a configuration file. This file is used by all the tools.

Here is the connection control


The password request form (as passwords are not stored in the configuration file)


And actually, the form which allows to select one of the existing connections configuration. It is used when an action requires an active connection to a CRM Server.


In order to help you to download all updated tools, I created an archive containing all tools.

Thursday, November 5, 2009

Who customize what and when?

The customization feature of Microsoft Dynamics CRM 4.0 is well known for being one of its best strengths. However, it lacks one essential feature nearly: The monitoring of theses customizations.

Indeed, it is impossible to know who does what in terms of customization and above what customizations were published.

With plugins and the famous capabilities of customization, it is relatively simple to set up an event log of customizations in Microsoft Dynamics CRM 4.0.

What you need is Plugins and one Custom Entity (let say “Customization Log”)


Microsoft Dynamics CRM 4.0 provides us with several messages that allow us to track what is happening in terms of customizations the application.

There are two types of messages:

  • Import Messages
  • Publish Messages

Import Messages

They can give you two pieces of information:

  • The customization file that was imported (CompressedCustomizationXml property)
  • The entities or parameters that have been imported (ParameterXml property)

The messages are:

  • ImportCompressedAll
  • ImportCompressedWithProgress
  • ImportAll
  • Import
  • ImportWithProgress

Catch all these messages to be sure to monitor every import event.

In the case of imports, you can retrieve the customization file in the incoming properties (CompressedCustomizationXml) of the plugin context. So you can get the customization file during PRE stage (context.Stage == 10).

Publish Messages

They provide us with the list of entities that have been published (through the property ParameterXml of the plugin context).

The messages are:

  • PublishAll
  • Publish

Knowing this information, it is possible to export published entities customizations.

In the publish case, we only know the names of entities that are published. So, we must therefore export customization during POST stage to retrieve the customization file for the published items.

The plugin Process

In both cases (Import and Publish), we saw that we have the list of imported/published entities and the associated customization file.

So, our plugin has only one thing to do: create a record of "Log customizations" entity type that will contain the following information:

  • The type of operation: Import or Publish (which can be displayed as a picklist)
  • Entities involved stored in a memo field (because you can potentially have many imported/ published entities - Beware the maximum field size, therefore)
  • The customization file as an attachment

To make all this easier to use, we will take care of:

  • Bringing the notes section on the form first tab
  • Displaying the columns “type of operation”, “Actor”, “transaction date” and “entities involved” in the "Active Customization Logs” view.

Here it is! You have a monitoring feature for your customization !

BE AWARE of handling all exceptions because your imports will not work anymore if the plugin throw an exception

NOTE : To compare two customization files and know what have been updated, you can use the CRM Customization Comparison Utility provided by Microsoft on the CRM Team Blog

Custom web application and bin folder... Yes, but...

As you can see on the Best Practice of the CRM SDK (, since rollup 2, you can put your custom assembly to your own web application bin folder instead of using the bin folder of the CRM web application.

Since a while, I didn't understand why this practice seemed to work for everybody except me...

The answer is simple: The assembly name can't contain any dot if you want it to work... It is a known bug by Microsoft.

As I was used to name my assemblies like .Crm.Web, it couldn't work...

I hope this will help some of you, guys!