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).
Namespacing
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 https://www.nuget.org/packages/PageBuilderContainers.Kentico/ and https://www.nuget.org/packages/PageBuilderContainers.Kentico.MVC/ , 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:
- Make sure your GitHub ReadMe has all the items outlined on the Marketplace
- Fork the Marketplace Repository onto your own GitHub
- Create a Branch for your specific tool that you are submitting and pull that down onto your computer.
- 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).
- Commit and push your changes up to GitHub
- 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 https://devnet.kentico.com/marketplace . 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.