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.
Cannot Connect to an Dynamics365 instance
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 later failing) to connect to my online tenant I kept being greeted with a message that I could not properly authenticate to Dynamics365. Aside from the most common TLS issue, the real problem for me was that my version of the base Package Deployer did not jive what I was deploying too (I imagine due to changes in the ADAL library), once done, deployments went much smoother.
To save some time, I downloaded the latest and greatest tools from here which led to immediate success.
Configuring the Package
The Solution file deployment is still based on a set of dependencies so you want to make sure your solutions are in the right order. This is the best part of the Packager as this is the information that is always lost between developers that ends up requiring an extraneous doc to explain itself.
Once I compile and run the solution I now get this fancy screen that makes me look like a pro when it comes to deploying solutions. Notice here that I also force the activation of all components as well when deploying.
Package Deployer Gotchas
When I first compiled, I forgot to set my solutions in my Visual Studio project to “Copy Always” – this and the configuration of the solution file is a bit of a drag (unless you have it connected to your build system on check-ins). Also, whatever SDK you are using (i.e., Dynamics or CRM) you need to ensure that your Package Deployer solution is using the same framework. If not you’ll get that “Double-Click-Of-Death” where you click and click but nothing ever happens.
If you’ve done all of the above, you’ve done the base of what is required to get up and running with the Package Deployer – translation – we haven’t started on the really cool stuff yet.