Import CRM Dynamics 2015 Managed Solution - Exceeded Content Size

 I was importing a CRM Managed Solution and the import failed with the following error:

"The assembly content size '8399872 bytes' has exceeded the maximum value allowed for isolated plug-ins '8388608 bytes'."

I know you can argue that even for a dll can be to much and it was something Microsoft was trying to avoid, however sometimes can really happen. To overcome this issue, a key on the [DeploymentProperties] table can be updated to a bigger value.

With me the problem was the utilization of an external dll that i used for some testing, totally forgot to remove the reference.

But, if in anytime someone has to use a dll that has more than 8.192 of size, the default of CRM, the following sql query can override that value for a bigger value.

update [MSCRM_CONFIG].[dbo].[DeploymentProperties]

SET [IntColumn] = 16384
WHERE [ColumnName] = 'SandboxClientMaxAssemblySizeInKByte'

Hope it helps.

CRM 2015 - UR 0.2 - Export to Excel

 Just found today after installing UR 0.2 for CRM 2015 that when exporting data, i didn't have anymore the check box for being able to import data again back to crm.

However, opening the excel file i have found that the columns were starting in 'D' instead of 'A', so it means that we no longer need to set any check box for that.

Another thing i really liked was, the excel file extension changed from .xls to .xlsx and in here i have to say that i was expecting this even since CRM 2013 or something. Now that is done, i would say, is always better later than never. :)

Good news as well, it is possible to import an XLSX file. Saying this because i have tested.

Thank you Microsoft.

For the list of additional features and characteristics of the new Export to Excel functionality please see go to the link.  

Hope it helps.

Configure Exchange folder-level tracking rules

 If you need to configure a specific Microsoft Exchange folder to track the emails and run a workflow process configured in crm, it is possible trough few lines of code.

Let's assume that you have configured a folder in the Microsoft Exchange to keep emails sent by a specific (individual contact or company).

The code needed for this is:

To create and manage folder-level tracking rules:

// Create a folder-level tracking rule 
MailboxTrackingFolder newTrackingFolder = new MailboxTrackingFolder(); 
// Set the required attributes newTrackingFolder.ExchangeFolderId = "123456"; 
// Sample value. Retrieve this value using Exchange Web Services (EWS) 
newTrackingFolder.MailboxId = new EntityReference(Mailbox.EntityLogicalName, _mailboxId); 
// Set the optional attributes 
newTrackingFolder.RegardingObjectId = new EntityReference(Account.EntityLogicalName, _accountId); newTrackingFolder.RegardingObjectId.Name = _accountName; 
newTrackingFolder.ExchangeFolderName = "Sample Exchange Folder"; 
// Execute the request to create the rule 
 _folderTrackingId = _serviceProxy.Create(newTrackingFolder); Console.WriteLine("Created folder-level tracking rule for '{0}'.n", _mailboxName);

You can create a maximum of 25 folder-level tracking rules per mailbox.

To Retrieve folder-level tracking rules for a mailbox:

// Retrieve the folder mapping rules for a mailbox  RetrieveMailboxTrackingFoldersRequest req = new RetrieveMailboxTrackingFoldersRequest { MailboxId = _mailboxId.ToString() };  RetrieveMailboxTrackingFoldersResponse resp = (RetrieveMailboxTrackingFoldersResponse_serviceProxy.Execute(req);  Console.WriteLine("Retrieved folder-level tracking rules for {0}:", _mailboxName);  int n = 1;  foreach (var folderMapping in resp.MailboxTrackingFolderMappings) {   Console.WriteLine("tRule {0}: '{1}' is mapped to '{2}'.", n, folderMapping.ExchangeFolderName, folderMapping.RegardingObjectName);   n++;  }

Code in here from CRM 2015 SDK.

Hope this can be helpful. 

Single long workflow vs Multiple Child Workflows

 Usually i'm more for plugins instead of workflows, here it is more a personal opinion, but i never say, never develop a workflow to someone, and i develop workflows if they make sense.

In this case, lets assume that for some requirement is better to develop a workflow instead of something else.

Let's assume as well to make sense that that workflow will be used for multiple scenarios. 

So, in here, should we use a long workflow or a workflow with multiple child workflows?

Based on some articles from the SDK and Technet, we should prefer to develop a long one, and why? The reason is that "the overhead occurs when all entities that are used in the workflow are retrieved and the child workflow is started in a two-step process that includes a 'Workflow Expansion Task' and the actual workflow instance. Therefore, for maximum throughput, use a single long workflow."

So, "for maximum throughput, use a single long workflow."

Information from CRM 2015 SDK.

Hope it helps.