Backing up plugin/workflow assemblies

One of the ways to quickly backup the plugin/assemblies that are stored in the MSCRM database is to use the Assembly Recovery Tool that comes with XrmToolBox. Recently, I had a situation where I couldn’t back up the assembly this way, as one of the assembly was huge and the OrganizationService was experiencing some latency issues, resulting in a slow performance of the Assembly Recovery Tool.

I followed the method below to quickly backup the assemblies straight from the database.

  1. Install CShell. I prefer this over Linqpad for quickly running C# snippets because you get intellisense for free and it also has a REPL window.
  2. Run the query which is below in SQL Server Management Studio, against the MSCRM database
    SELECT [Name],[Content] FROM dbo.PluginAssemblyBase WHERE IsHidden=0
  3. Right click on the result and choose “Save Result As” from the context menu and specify the file name and the location
  4. Run the code below in the CShell scratchpad
    var pluginCsv = System.IO.File.ReadAllLines(@"[FULL PATH OF THE SAVED CSV]");
    foreach(var l in pluginCsv)
    	var content = l.Split(',');
    	var assembly = Convert.FromBase64String(content[1]);
    	System.IO.File.WriteAllBytes(string.Concat(@"[OUTPUT PATH FOR THE ASSEMBLY]",content[0],".dll"),assembly);

All the assemblies should now be saved to the specified folder. You can use this technique to restore assemblies from database backups of the MSCRM database.

New calculated field functions in CRMOnline Update 1

I logged a suggestion in Connect long time back, about lack of DATEDIFF function option in calculated field (

Quite to my surprise, CRMOnline Update 1 (Carina) now has a bunch of new DATEDIFF functions. These are


There is also an additional function “NOW”, that gives you the current datetime. According to “NOW” returns SQL Server UTC Time and not the user’s local time. This is true, only if the datetime field is Time Zone Independent. If the datetime field is created as User Local, “NOW” returns user’s local timezone.

If you try to use NOW function in a datetime field with behaviour Time Zone Independent, you’ll get “You can only use a Time-Zone Independent Date Time type field” error message.

The trick to getting UTC time in this case, is to first create the datetime field as User Local, fill in the calculation field action, and only then change the datetime behaviour to Time Zone Independent. Also note that, it is possible to change the datetime behavior from User Local to Time Zone Independent, but not the other way around (from the UI).

I created two calculated fields using NOW function, one is User Local and one is Time Zone Independent. After doing an Advanced Find with the attributes, here is the result.

DIFFINYEARS and NOW in combination, can be used in scenarios like calculating Age from Date of Birth, days since record creation, days to hit a certain deadline. These calculations, which were once accomplished by a running a periodic workflow or service, are trivial to implement with calculated fields. For eg. age calculation

This is the Advanced Find result

These great additions in the Spring Update, make calculated fields more powerful than ever.

Quicktip: Install .net 4.5.2 before developing for CRM2015

Before you start developing console application, workflow or plugin for CRM2015 the first step is to install .net 4.5.2 as this is required by CRM2015. I was working on a simple console application using CRM2015 assemblies and I encountered a weird error. I ran “Install-Package Microsoft.CrmSdk.XrmTooling.CoreAssembly” from the PM console without any issue. But when you try to build the application I got these compilation errors.

The root cause of these errors is because the project is not targetting .net 4.5.2. Download .net 4.5.2 from and update the project target framework to .net 4.5.2. This time the build process succeeds. I was quite surprised that nuget did not prevent me from using the package in the project, even though I didn’t have a the prerequisite framework version.

Calculated Fields in CRM 2015

Calculated fields are new to CRM 2015. Business Rules now also have a new Entity Level scope option. When it comes to simple decimal operations you can use either Business Rules at Entity Level scope or calculated fields. Obviously calculated fields, are much more powerful than business rules. There is one issue I experienced with business rules at entity level. The division operator currently does not seem to work properly.

This the business rule to perform the division.


When you save the record an error is displayed.

This is the actual error

Unhandled Exception: System.ServiceModel.FaultException`1[[Microsoft.Xrm.Sdk.OrganizationServiceFault, Microsoft.Xrm.Sdk, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35]]: Expression operator not supported for specified type.Detail: 
<OrganizationServiceFault xmlns:i="" xmlns="">
  <ErrorDetails xmlns:d2p1="">
      <d2p1:value xmlns:d4p1="" i:type="d4p1:string">0</d2p1:value>
      <d2p1:value xmlns:d4p1="" i:type="d4p1:string">-2146233088</d2p1:value>
  <Message>Expression operator not supported for specified type.</Message>
  <InnerFault i:nil="true" />

[Microsoft.Crm.ObjectModel: Microsoft.Crm.ObjectModel.SyncWorkflowExecutionPlugin]
[c3877360-9a7d-e411-80cf-e83935c2f340: ]
Starting sync workflow 'Decimal Formula', Id: bc877360-9a7d-e411-80cf-e83935c2f340
Entering ConditionStep1_step: 
Sync workflow 'Decimal Formula' terminated with error 'Expression operator not supported for specified type.'


The calculated field that performs the division works without any issue.

Interesting behaviours that I encountered below.

Scenario 1: Calculated field to divide two integers and the result of the operation is float e.g. : 5 / 2

Result: The result is rounded up to the closest int.

Scenario 2: Calculated field – Divide by zero

Result: No divide by zero exception. The result is blank.


Scenario 3: Calculated field of type text, with calculation using decimal fields.

Result: No error. Result of the operation is can be assigned to the string field.


Conclusion: If it can be done using calculated fields, do it that way, instead of Entity scope business rules, as calculated fields offer much more flexibility and functionality.