What’s this about?

This is about TagHelper’s in ASP.NET Core, and how to get more flexible @addTagHelper directives.

Suppose your application loads some assemblies dynamically - for example, from a plugins folder, and those assemblies contain TagHelper’s.

In startup.cs you would have something like this to register your assemblies with the MVC parts system:

1
2
3
4
5

var assy = Assembly.LoadFile("C:\\SomePath\Plugin.Authentication.dll");
mvcBuilder.AddApplicationPart(assy);

var assy = Assembly.LoadFile("C:\\SomePath\Plugin.Markdown.dll");
mvcBuilder.AddApplicationPart(assy);

Now suppose you have a Razor View with some markup that can be targeted by those tag helpers:

1
2

 <plugin-authentication />
 <plugin-markdown visible="true"/>

If you run your application, those TagHelper’s won’t work. This is because you don’t have any @addTagHelper directive yet in your razor view, and so razor doesn’t know it should be using them. This is where things get a bit interesting!

DnnPackager Release -v2.0.6

A short post to announce that a new minor release of DnnPackager is out. You can find the release notes here explaining what’s new: https://github.com/dazinator/DnnPackager/releases/tag/2.0.6%2B2

For an introduction to DnnPackager in general see here

Special thanks to @nvisionative for requesting this feature.

Sources Packages

I have been doing some work on DnnPackager recently, and I’ve come accross the concept of “Source” packages. I have to admit I am not entirely new to these, but I’ve never personally used them for my projects in the past.

Source packages are basically identical to the ordinary install zip’s for your dnn module / extension, i.e you “install” them into your Dnn site like any other install package, except that they also include “source code” files within them, like .cs, .vb files etc.

Why would you want to include source code in your install zip?

Well this is where things get a little interesting.

This post is part two of a series. For part one see here

Part 2 - Replacing Bower with JSPM

In part 1 of this series we created a shiny new ASP.NET 5 project, and I introduced some fundamentals.

For reasons discussed in part 1, let’s now go ahead with our first task, which is to ditch Bower in favour of JSPM as our javascript package manager.

Introduction

When developing DotNetNuke extensions, we typically use one of the existing Visual Studio Project Type’s, for example - an ASP.NET Web Application project.

Even when using a Project Template such as Christoc’s, the project template is still based upon one of the standard Visual Studio project types - usually an ASP.NET Web Application project.

However these Project Types do not “gel” well with DotNetNuke development in a number of areas, the main ones being:

1. Running the project in VS (clicking play) - wants to run the extensions as a Web Application, but this makes no sense for a Dnn extension - which has to be hosted by the DotNetNuke website.
2. Deploying the extension - there is no support for that in the project system - you have to manually deploy your extensions to the Dnn instance.
3. Debugging the extension - you have to manually attach to process.

So.. what if there was a new Project Type, one that was purpose built for DotNetNuke development? What would that look like?

Dnn Packager - Super Smooth Module Development

In this post, I am going to show you how to get up and running with DnnPackager for your DotNetNuke module / extension development.

Tools of the Trade

I am using VS2015 Community Edition, but this should work equally well with previous versions.

First Off..

This article is for those of you out there who use Xamarin to write Android applications and want to automate the process of running your tests on an Android device. I’ll show you how you can set this up with relative ease.

Here is the process we want:

This post is part 1 of a series. Part 2 is here

ASP (A Sea of Packages).NET 5

When you create a new ASP.NET 5 project, you will see all sorts of new-ness. I am going to guide you, the uninitiated ASP.NET 5 web developer, through creating your first ASP.NET 5 MVC application, but we won’t stop there. In the next post of this series, we will then enhance the project with a number of features:

1. Bundling and Minification.
2. Auto browser refresh (as you make changes to files during development)

In addition, I will touch upon important tooling that you need to be aware of:

1. NPM
2. Bower and why we are going to replace it with Jspm
3. Gulp - and why is it useful

To be able to do all of this, we will be creating an ASP.NET MVC 5 project, and then we will be using Aurelia to run an Aurelia application on Home page (Index.cshtml)

Module Debugging - Two Approaches

When developing DotNetNuke modules people take many different approaches but they boil down to two alternatives in terms of workflow:

1. Placing / checking out your source code directly into the \DesktopModules folder of a DotNetNuke website, and having your module dll’s output to directly into the DotNetNuke website’s \bin folder.

2. Checking out and working on your code wherever you like, but having to deploy your module (content and assemblies) to a local DNN website when you are ready to run it.

Both approaches require that you “attach to process” from within Visual Studio in order to debug your module.

Automating DotNetNuke Deployments using Octopus Deploy

Because I am an awesome dude, i’ll share with you how I automate dotnetnuke delivery / deployments. This works. It takes some effort to get this set up though, but it will be well worth it in the end.

First i’ll explain the process for automating the deployment of the DotNetNuke website itself. Then I’ll explain how you can automate the deployment of modules / extensions on a continous basis.

Preparation work

1. Set up a brand new DotNetNuke website, and go through the install wizard until you are greeted with an empty default dotnetnuke website.
2. Stop the website. Create a NuGet package containing the website folder.
3. Put that on your internal NuGet feed.
4. Go to the dotnetnuke database, and generate the create scripts (with data).
5. Create a new console application that uses dbup to run the above sql scripts when it is executed (as described here). Remember to replace things like server name etc in the sql scripts with appropriate $variablename$. Dbup can substitute $variablename$ in the sql scripts with their actual values (which you can pass through from Octopus) before it executes them.
6. Add OctoPack to your Console Application so that it is packaged up into a NuGet package. Put this NuGet package on your internal NuGet feed.

You should now be in this position:

1. You have a NuGet package on your feed containing the DotNetNuke website content
2. You have a NuGet package on your feed containing your wonderful console application (DbUp) which will run the database scripts.

Next Step - to Octopus!

1. Create a project in Octopus to deploy a “DotNetNuke” website. For the deployment process you will need the NuGet packages prepared previously. The deployment process should:

2. Create a website in IIS using the website NuGet package.

3. Create the database by executing the executable within the Database NuGet package.

There are lot’s of things to remember when deploying dotnetnuke. I won’t go into detail but things like:

• Granting full permission to the app pool identity that the website runs under to the website folder.
• Updating the portalalias table with appropriate access url.

… and other things. The Dnn install process has been covered elsewhere so I won’t go into any further detail here.

Congratulations (partly)

You should now be in a postion where you can roll out a DotNetNuke website via Octopus.. BUT WHAT ABOUT THE MODULES I’M DEVELOPING!! - I hear you exclaim.

Automating Module Deployments

1. When you build your module projects (via build server etc) you want them packaged as DotNetNuke install packages, inside a NuGet deployment package, which is then published to your NuGet feed. You can use DnnPackager for this (which is something I created).

2. You’d need something that can copy a set of zip files to the “Install/Module” folder of a DotNetNuke website, and then monitor that folder, whilst calling the DotNetNuke url to install packages (www.dotnetnuke.com/install/install.aspx?mode=installresources). I wrote a quick console application to do this. It repeats calls to that URL all the time the number of zips in the install folder decrements (dotnetnuke deletes them after they are installed). If after x calls, there are the same number of zips left in the directory, it assumes they cannot be installed and reports a failure (return code). You should package this tool up into a NuGet package and, you guessed it, stick it on your internal feed.

3.Create a project in Octopus for “Module” deployment. You want the deployment process to:

• Dowload the NuGet package containing your module zips.
• Download the NuGet package containing your module deployment utility (that console app i spoke of)
• Invoke your deployment tool exe, passing in arguments for where the module zip files were placed, what the website url is, and potentially the path to the Install/Modules folder on disk (although my own tool interrogated IIS based on the website URL to find the website directory)

## Full Congratulations

You will now find that you can create a release of your module project in Octopus and deploy all your lates modules to any DotNetNuke website at the push of a button.