Why not use a DotNetNuke Project Template!?

Many people may choose to use a project template such as the following, in order to streamline DotNetNuke development: https://christoctemplate.codeplex.com/

These templates may work for many people. But I have never got on with them, for a number of reasons.

1. If the author of the project template fixes a bug, adds a new feature, improves build logic - how do I obtain that new functionality in my existing projects, created using the older version of the template? The answer is I can't very easily do this. I can only get those gains for future projects that I create, explicitly using the newer template.

2. They often introduce the requirement that developers checkout their code to a particular directory - i.e the "DestkopModules/modulename" folder within a local Dnn Website. I don't agree with this coupling between a project and it's location on disk. I prefer to keep projects agnostic when it comes to location on disk. They should "just work" no matter where a developer chooses to check them out too. Many of these templates assume the build is occurring within a particular website directory, and formulate all sorts of paths based on this.

3. It can lead to a process where developers only run the install / deployment process once, then proceed to make many changes to the code, adding files / dependencies etc, without ever re-testing that module installation process. Later on, when the module is released or pushed to a CI server, the installation issue may become apparent during that process (i.e forgetting to include a dll etc). I prefer to catch these issues earlier, during development, before it potentially goes out to a user or QA environment, or causes the CI server to fall over. One way of doing that is to ensure that the DotNetNuke module installation process is the **sole ** mechanism by which any developer deploys changes for the module, which includes to their local development instance of DNN. This ensures that the deployment process is constantly tested, and reduces the chances of issues happening further down the line with dodgy installations.

4. I don't like the fact that most of the DotNetNuke project templates that I have seen are set up to include particular dependencies - for example Dnn7 dll's. I'd rather create a project, and be free to add the relevant NuGet packages for any dependencies I need, as opposed to having a project template for Dnn 5, another for Dnn 6, another for Dnn 7 - each with different sets of dll's included.

Overall, I feel the Project Template idea isn't the best approach. Hence DnnPackager was born to try and create a better one.