I love getting these error messages when using the Dynamics SDK!
I immediately know where to go to resolve the problem when it happens 🙁
If you are trying to diagnose precisely where the issue is in your code, the “Reason” member won’t have this data – probably because it’s not at the top of the stack and you need to dig deep to see what’s what.
To get to the nitty gritty of what is happening you will need to dig into the InnerFault of the Detail member to see what has really happened.
When deploying solutions, you can’t include Business Units in your solution file and if you are needing to create many of them, this can be a bit of a hassle.
I recently had this problem where I was working on a project that had many units that I didn’t want to create manually, so I turned my eyes to the SDK in order to take this task from 20 minutes to 1.
The Parent Business Unit
The most important thing with Business Units is to remember their hierarchy. Irrespective of how you have setup your system, you will always have a top-level unit that everything else inherits from.
When trying to find this unit (to then extend from) all you need to do is query for the businessunit that does not have a parent
Continuing off of last week’s Package Deployer post I needed to add some extra functionality into our deployment that required the configuration of some steps that we were doing manually but now wanted to be done in a more automated fashion.
The task to accomplish this isn’t too hard and can be done relatively easily.
The first step involves decided “where” you want your code to execute. In my scenario, I wanted my code to Run after I had deployed all my customizations to the target tenant. In my example, I am deploying a base configuration after everything has been deployed. The “this.CrmSvc” is part of the runtime of the Package Deployer code which lets me access the current connection to Dynamics365.
//Implement the Default Configuration.
ValidateConfiguration config = new ValidateConfiguration(this.CrmSvc);
Read More
I was looking to automate some of my solution deployments for customers to simplify the deployment of solutions into new environments and ensure the right steps were being followed pre and post deployment.
To do this I wanted to leverage the Package Deployer from Dynamics. There is already some pretty good information on how to get started building your first package, however I ran into a few problems not covered in the documentation.
There are many articles on this topic as it ranges from TLS to security permissions, however for me, it came down to SDK versions. I generally work on a number of different instances across many customers and versions so I need to keep my versions strongly in check. As such, when trying (and
No matter what project you are on, you are at one point or another going to need to delete data.
Your environment will become polluted and you going through each entity or manually queuing up your own delete jobs will not be worth your time.
To bulk delete your entire environment you can make use of the Bulk Delete API with the following lines of code.
QueryExpression bulkquery = new QueryExpression();
bulkquery.EntityName = entity.LogicalName;
bulkquery.Distinct = false;
BulkDeleteRequest request = new BulkDeleteRequest
{
JobName = String.Format("System Purge Requested for Entity [{0}] - All Records", bulkquery.EntityName),
QuerySet = new[] { bulkquery },
StartDateTime = DateTime.Now.ToUniversalTime(),
ToRecipients = new[] { currentUserId },
CCRecipients = new Guid[] { },
SendEmailNotification = false,
RecurrencePattern = String.Empty
};
ExecuteMultipleResponse response = new ExecuteMultipleResponse();
response = (ExecuteMultipleResponse)_svc.CrmService.Execute(multipleRequest);
Of critical importance is the