Creating a web version of the plugin registration tool

For the last month or so I have been trying to create a web-only version of the plugin registration tool. As much as I’d like to say it’s done, it’s not the case. Looks like, at least for now, I just have to put it on hold since this has been taking an absolutely insane amount of time.

Still, there is a bunch of things I have learned/experienced first-hand, so that is what I wanted to share. What I learned in the last month.

I’ll probably split this into two different posts, though.

Technical

• There is nothing preventing us from creating our own file upload UI elements in Dynamics. That’s right, the concept of using  “notes” as the only option for file uploads is officially deprecated(and has been for a while). HTML5 combined with javascript and plugins can do wonders
• As of now, it seems nothing can beat custom actions when you need to create an interface between your javascripts and plugins
• Technically, plugin registration tool seems to be using unsupported techniques to deploy plugins in Dynamics. Which is fine, though, since it’s provided as part of the SDK. Note: prior to writing this post I though I saw a reference somewhere on msdn where content attribute of the PluginAssembly entity was marked “for internal use” or something along those lines. I was not able to find that reference later, though, so it might be just my imagination
• There are some drawbacks associated with using custom actions to store configuration settings

Project-related

• When planning a Dynamics project, you have to think of the people resources carefully. The complexity of those customizations can vary a lot, and, quite frankly, this time it was a bit too much for me since I probably had to spend more time catching up on the usage of Vue, for example, than doing actual development
• You also have to think of the architecture and consider the limitations. For example, when I’m thinking of XrmToolBox, I realize it’s a very useful tool(or should I say framework?) Still, personally I favor those tools which are deployed directly in Dynamics.. those I can use without having to install anything on my machine. Problem is, not everything is easily doable in that architecture, and, also, that kind of development requires different skillset

I will cover all of the above in more details, but, if you are interested in what I’d call the “proof of concept” of the web-based plugin registration tool, you will find all the sources here:

https://github.com/ashlega/ItAintBoring.DevTools

It is just that at this point – proof of concept:

What’s important is that it runs as a web resource in Dynamics, and you can actually upload a file and register it as a plugin assembly (including all the plugins). Whether this proof of concept will ever turn into a working “product” is a good question.. but, with that, let’s continue to the technical lessons learned