The Package Deployer is a great way to move solutions between environments consistently while enabling you to do things like custom tasks and migrating data at the same time.
I hadn’t looked into the data facilities of the Package Deployer but had a project where we were doing more and more manual data imports (small files) so decided to take the leap and see how it works.
There is some good and some bad.
I’ve been working with a customer doing some SharePoint integration with Dynamics365 and when we went to do the first step (which is the simplest) of turning it on. I then went to access the Document Management section of the Account entity only to find that it was gone and not there.
This was a bummer.
In working to get this back, there are two solutions I looked at, both worked.
There is a great article here on how to add the Navigation link back in for Documents. I had never done this before, so this was interesting to do. The directions here are straightforward and easy to follow;
This workaround is a little more involved. But I have
A little known issue that you might see crop up from time to time is when you go to download your zip file from the customizations section of the USD you are immediately presented with an error that the “Record is Unavailable” even though it clearly is.
This can be incredibly painful because sometimes all you need to do is update a configuration and redeploy.
Getting to your file is possible, but requires a few extra steps.
Using Advanced Find, search against the Annotations/Notes that you are looking for (in my case USDQueueControl.zip.
Read More
Running simple, one-hit code tasks in the Package Deployer is pretty easy and works when you have one or two projects that you are working on.
However, I’m pretty lazy and not much for running the same patterns over and over again.
To this end, I came up with a Framework that requires you to only code your Package once while letting you maintain your tasks in another project that you don’t need to reference directly.
The implementation is accomplished via an Interface library that gets shared between projects. In this case, I called it “IDeploymentTask” and gave it some property and events to be used while it does it work so it can update the UI accordingly. This interface is located in a common project that both my Package Deployer users
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);
string configResults =