skyehoefling / dnn-build-tools

DotNetNuke Build Tools for packaging modules

Skye (she/her)

Hello 👋

My name is Skye and I am a Senior Software Engineer II @ Blizzard Entertainment working on Diablo IV
I used to make open source software

🎮 Gaming 📱 Mobile 💻 Cross-Platform

Languages

                 

Gaming

 

Platforms

       

UI Toolkits

     

IDEs

           

dnn-build-tools's Issues

DNN Build Tools NuGet Structure

Background

DNN Build Tools removes the burden on DNN developers to maintain an independent fork of the community build tools/scripts that just about every DNN Module relies on. These tools automatically package up your module in Debug/Release mode depending on configuration. If you are unaware of what I am talking about, you might have seen something like this in your DNN Module

The ModulePackage.targets file provides MSBuild targets that automatically run depending on your configuration. Many DNN modules including core modules use these build tasks and each project maintains their own fork of these scripts. Which is really fine if you need to do something custom. There are many different build tools out in the wild and there isn't one way to solve this problem and there shouldn't be only one way as different projects have different needs. For example yarn is great for building frontend projects, don't forget gulp, and npm. You can even use WebPack with it to simplify how your bundle gets generated. Cake is a great build toolchain for creating a C# Make file.

The majority of DNN modules aren't doing anything custom, they are following standard software design techniques and just need a package installer. This is independent of how the front-end is built including the front-end build tools such as gulp. yarn, npm, etc. In my opinion this create a difficult barrier to entry in DNN module development.

DotNetNuke.Build

Enter my new project DotNetNuke.Build which is going to be a NuGet package that you install into your module that automates packaging for you. Here are the getting started steps

1. Create DNN project using a standard template (The standard template is TBD)
2. Include correct NuGet reference for DotNetNuke.Build
3. Build project in release mode
4. Install DNN Package to your DNN site

There is no need for managing the build steps they are just included as a NuGet reference and automatically executed during the MSBuild.

When building a DNN site a required artifact for everything to work is the DNN Module Installer or the package archive zip file. For a long time in DNN many developers have manually built these via automated scripts or the community build tasks. This should be the last thing a developer worries about, they should just know to build their solution and look in the bin directory for their artifacts. If the project requires any special automation they can add it on top of the DotNetNuke.Build tools.

How does it work

DotNetNuke.Build will publish a NuGet package with the following package ids

• DotNetNuke.Build.Mvc
• DotNetNuke.Build.WebApi
• DotNetNuke.Build.Html
• DotNetNuke.Build.WebForms
• etc.

That will load the correct packaging build scripts for the specific module and invoke the steps at build time. All you need to do is add the reference to your csproj file

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="DotNetNuke.Build.Html" Version="1.0.3" />
  </ItemGroup>

</Project>

Request for Feedback

While I research this topic I am interested in community feedback. If you were to adopt this toolchain to simplify your build environment what makes the most sense?

• 1 NuGet reference for any project type
• A NuGet reference for each project type