Innovate with AI-driven insights
Create virtual agents, empower managers with actionable insights, and guide agents to the right outcomes.
Dynamics 365 2019 release wave 2 plan Discover the latest updates to Dynamics 365.Release Plan | Weekly Deployment Notes
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants.Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements.
ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Talent TechTalks
Just a quick update to note that the Alternate Key Manager XrmToolBox tool is published and available for download!
Why a full post? Well, I just wanted to post a few notes about deploying XrmToolBox plugins because I had a few issues with this plugin… all issues attributed to user error.
The XrmToolBox Plugin Store is pretty cool as it leverages NuGet.org to manage the list of available plugins. The Plugin Store queries published packages for those that include the tag XrmToolBox, and this is the list that is available for install and update on your local system. How do you ensure your plugin is listed? This article on the XrmToolBox portal outlines the process in nice detail: Deploy your plugin in Plugins Store.
The article explains how to use the NuGet Package Explorer to define and publish you plugin. This is a nice utility for creating and editing NuGet packages. This is essentially an editor for the standard nuspec xml used by the NuGet command line tool to generate your package, showing all fields in a package, allowing you to define dependencies, and add your assemblies to a package.
Using this tool is a great way compile and review your work before publishing. If I had used this tool, I might not have bungled my deployment!
If you do not want to use a tool like the NuGet Package Explorer, you can write the nuspec xml manually and build the package using a command line tool. This is what I have been doing since it’s fairly easy to maintain. When starting a new project, I just copy my previous nuspec Xml as a starting point and edit the fields for the unique name, title, project URL, etc. For the Alternate Key Manger plugin, I packaged things up a few days ago, published, and eagerly awaited the new plugin to show in my XrmToolBox Plugin Store! But… it never showed up in the list. The odd thing was, I could see that it was being downloaded from the NuGet admin page for the package. What the heck was going on?
Thanks to Jonas Rapp for the suggestion to check out the Plugins page on the XrmToolBox portal. From here, I could see all plugins, including my own, and I quickly discovered my problem.
Unfortunately, I did not check my work and when I uploaded my NuGet package, I left the Title as Document Template Manager! Sure enough, NuGet shows the wrong title though everything else looks correct.
So when the XrmToolBox plugin Store pulled the list, it actually grabbed my new plugin, but since I used the incorrect name, I could not find it.
A nice and relatively harmless case of learning to check your work before deploying. A good lesson for LOTS of different situations!
Fortunately, all I needed to do was increment my version and update the incorrect xml tags and all is fixed. I uploaded my repackaged plugin and once verified, unlisted the old version.
So some quick takeaways from this harrowing experience:
Business Applications communities