Submitting Components to Kentico Marketplace

What's new on the Marketplace

Kentico has had a Marketplace for a long time, longer than I've been working with Kentico. The Marketplace has been a place to share useful tools and components with the world. I've been a big proponent of the marketplace, submitting and maintaining over a dozen tools throughout the years in order to help other Developers get the most out of Kentico. However, the marketplace hasn't been without it's issues. It's been sorted purely by submission, leaving some popular and up kept tools to lag behind. It also has been host to many "one off" tools that were available for only one version, and never updated, and it was sometimes hard to navigate and took time to get items published on.

With Kentico 12's move to MVC, the Marketplace has been redefined. The new marketplace will be driven off of GitHub, with a focus on making tools that are kept up to date, open sourced (to allow others to help upkeep tools), and also focused on using modern technologies such as NuGet for easy package installation.

I've been working with Kentico as an MVP that focuses on Developer tools on understanding their ideas and thoughts for the Marketplace and how to build components. I've gone through a couple iterations of building components, and with discussions with Kentico and other developers, come to find that there multiple approaches and pros and cons to each. In this article, I am going to outline the Kentico recommended approaches, and an alternative approach and discuss how each fits in so you can choose what will be ultimately best for you.

Two Ways - Kentico Component Starter & Shareable Component Boilerplate

Kentico Components Starter

Kentico has provided it's EMS MVC Component Starter repository that users can fork. This repository featuers a complete installation guide to set up Kentico 12 with the starter site. The idea is that you can start with this repository and then create your own components. It also guides users to install useful tools such as NodeJS and TypeScripting has examples of using these.

Shareable Components Boilerplate

This Repository Template is something I cooked up myself. It provides a clone-able starting point for your components, featuring an easy RenameProject.bat that automatically configures all the files, projects, and references for your new component, and has NuGet package generation ready.

Included Projects


Kentico Components Starter

Of the two repositories, Kentico Components Starter is more 'complete' that it actually shows how to install Kentico 12 and includes the full MVC Project. This can be good if you don't have an existing Kentico 12 site. However, I've found that most Kentico developers already have a Kentico site that they use for tool building.


Shareable Component Boilerplate

My Shareable Components Boilerplate is only the Project files for the components, that you can easily add to an existing Kentico 12 site. While it can be good to have the full MVC site included in your repository for completeness, having multiple tools would requires an MVC isntance fore ach tool which I found cumbersome. I prefer keeping my tools separate from my MVC site for that reason.

Development Time


Kentico Components Starter

Due to the setup of the MVC site, and configuration and installation of various tools in the Kentico Component Starter project, ramp up time is going to be slow going, and may require more of a time investment to get a project up and ready to share.

Shareable Component Boilerplate

If you want to get a component built and shareable, you can't beat the speed of my tool. With it I was able to take the TinyMCE_Wysiwyg tool that we developed previously and separate it, add it to my dev instance, build it into a NuGet package and submitted to the marketplace in about 15-30 minutes, and most of that time was just making sure I had all the pieces in place as I migrated the code.

Learning Curve

Moderate to Large

Kentico Components Starter

The Kentico Components Starter uses a lot of newer technologies such as Node JS, Typescript, Less processors, and other items. If you are a modern developer who has been in the MVC realm, then you'll probably do fine and the learning curve will be smaller. If you're a long time Kentico portal developer, many of these technologies may be new to you and hard to adopt.


Shareable Component Boilerplate

For my Shareable Component Boilerplate, there is really no learning curve. There is no technology that is leveraged besides the base Visual Studio, and I've included .bat files to help automate a couple items for you.

Project Types


Kentico Components Starter

The Kentico Components Starter kit has a lot of baked in power. Although I'm not as familiar with the technologies, some friends who are more comfortable with them have told me that the tools Kentico has in it's example can make developing advanced tools much easier. Especially if you get into Inline Editors that require more than a couple Classes and Views.


Shareable Component Boilerplate

My tool is bare bones, and doesn't include any toolsets to help develop larger scale projects. That's not to say that you can't add those tools onto my boilerplate, but as it stands it doesn't leverage technologies like Less / Sass processing and just uses standard MVC to begin with. If you are working on more advanced components you may want to include them.

NuGet Generation


Kentico Components Starter

Currently the Kentico Components Starter doesn't give any guidance on NuGet package generation. To be fair, it isn't THAT hard to generate a NuGet package from a class project, but as it stands you do need to handle this on your own.


Shareable Component Boilerplate

My tool preconfigures your nuspec file and already has the base setup of it. It also has a bat file that will generate your nuget package for you, which makes things a bit easier.

Which should you choose?

Based on this, I would recommend that if you are a MVC developer that is familiar and comfortable with more modern technologies, and plan on developing a more advanced and complex tool, I would probably go with Kentico's Component Starter.

If however you have a simple component (widget, section, or class library), it's hard to beat the quick startup time of my tool and the easy packaging. The separation and easy templating for your GitHub account is also a positive.

Other Recommended Practices

Assembly Versioning

Kentico is recommending that when you create your Assembly versions, you follow SemVer (Semantic Versioning), which means that the number increments indicate specific things. In the number 1.2.3, the 1 = Major breaking changes, the 2 = additions with backward compatibility, and the 3 = patches/bug fixes. When you fix some bugs, you increment the last digit, so if your tool has 1.2.3, and you fix a bug, the next would be 1.2.4

The downside of this is it doesn't contain any information of what compatibility this tool has for Kentico. Tools built for Kentico 11 won't necessarily work on Kentico 12, and it's hard to know if 1.0.0 was built for Kentico 11, or Kentico 12. Another method that I often employ is to use the first and second numbers to indicate the Kentico version this tool is for. So 12.0.1 means it works for Kentico 12, Hotfix 0 and above. Some of my tools span multiple Kentico versions, such as The Relationships Extended Module which has versions for Kentico 10-12.

Which you wish to do is up to you, Kentico's marketplace does have compatibility versioning information that you must enter when submitting your tool, so it isn't as big of an issue to use the normal SemVer methodology and start with 1.0.0, however when updating NuGet packages for your tools that are uploaded to NuGet, it is much easier to tell that indeed there is an update for your version of Kentico (if you are on 11.0.4, and there's an update for 11.0.5).


Kentico recommends that your tools have the Namespace of CompanyName.ToolName. This is probably the best way to go in almost all cases. I do have a couple tools that are already built and don't have the CompanyName portion of things that I really don't wish to refactor, so it is what it is.

One thing that you may also want to adopt, which Kentico has no quarrel with, is also including the postfix ".Kentico.MVC" for MVC packages and ".Kentico" for Admin (Mother) packages. This to me helps identify what packages are for which part of your Kentico. I have a and , the first for the Kentico Admin, the other for the MVC Site. This may be a good practice to adopt, plus it makes it easy to find NuGet packages in your searching.

Submitting to the Marketplace

Now to touch on how to Submit to the marketplace. Once you have your project published up on GitHub, and packaged on NuGet, it's time to submit it. Here's the processes:

  1. Make sure your GitHub ReadMe has all the items outlined on the Marketplace
  2. Fork the Marketplace Repository onto your own GitHub
  3. Create a Branch for your specific tool that you are submitting and pull that down onto your computer.
  4. Edit the Marketplace/extensions.json and add in your project to the end of the listing (make sure to follow the guide, and possibly add in an icon in the assets folder if needed).
  5. Commit and push your changes up to GitHub
  6. Go to your GitHub, go to your forked repository and your branch, and click on "New Pull Request" and create your pull request to pull your branch into Kentico's Marketplace repository

That's all it takes, not terribly difficult. Once they approve the pull request, it should show up on . You should hopefully see my 5 submissions up there soon!

Explaining View Compilation and NuGet Inclusion

Both my component repository and Kentico's feature a method of compiling views for your components using an msbuild targets file. In both repositories there is a Targets folder, which contain two .targets files. These contain MSBuild commands, which are executed on the build of each project (it's referenced as an import tag on the .csproj project files, you can open these with notepad or notepad++).

The Kentico.EmbeddedViews.targets is the important one, and I want to break it down so you understand it.

Here's the Embedded View Targets File

This is how the code works. The ItemGroup tag creates a variable ViewFiles and defines it as all the .cshtml files in the Views folder. Then It creates an EmbeddedInfo that loops through each item in the ViewFiles item group, and generates the Kentico.Web.Mvc.EmbeddedViewAssembly tag for each file, this is what Kentico uses to detect compiled and assembly driven views.

Next it makes a directory and outputs the content (WriteLinesToFile) to a ViewsPathGenerated.cs file, and adds that to the Compile. Then it uses an AfterBuild to copy the compiled library for your Views (which includes now both the compiled Views and the attributes) into the main project.

On the main project's nuspec file there is a File attribute that includes that View library in the nuget package, which as it packages up the main project will include this. This is how your nuget package will have both the code and the compiled views.

For more information on MSBuild, see it's documentation here, and more on Nuspec documentation here.

Wrapping it up

I don't know about you, but I'm excited to have the new marketplace in place and seeing others start to contribute. I also love that others can now help me make my projects better, and vice versa thanks to GitHub. Learning new technologies can be daunting, and I've had to make some adjustments to my methodologies as well. Kentico is doing a lot of things right, and hopefully this article and my tools can help you and spur further development.

Blog post currently doesn't have any comments.
= nine + six