Creating a web version of the plugin registration tool

By | April 22, 2018

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.


  • 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



  • 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:

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

3 thoughts on “Creating a web version of the plugin registration tool

  1. Prem Prakash

    Hi Alex,

    Greetings of the day!!

    I always wanted to understand the technicalities behind registering a dll on a particular message in dynamics, however I never tried digging deeper.

    Now that you have written prologue of it, sincerely waiting for the technical lessons.

    Great Work!!


    Prem Prakash

  2. Alan M

    Why are you wanting to create a web version of the plugin registration tool? Aside from the technical challenge, is there much of a benefit to doing so?

    1. Alex Shlega Post author

      Good question.. quite frankly, I think it’s been more of a learning exercise for now.. But the ultimate idea is to have CodeNow plugin for XrmToolbox implemented directly in CRM.. That would require some kind of plugin configuration interface, so why not to use a web-based plugin registration tool for that:)


Leave a Reply

Your email address will not be published. Required fields are marked *