Introduction

This is a blazingly fast intro to package targets, razor class libraries and static web assets, if you know what they are skip over to part 2 - where we do something with them

Ever since i saw Jason Elkin's amazing talk on Razor class libraries at Umbraco Together confrence, I've been itching to see how far we can take Razor class libraries and Umbraco packages.

This post is part of a series:

• Part 1 : Intro to Razor class library packages in Umbraco (this)
• Part 2 : Creating an Umbraco Razor class library package
• Part 3: Converting an exiting Umbraco package
• Part 4: Things I now do differently 🌟 New 🌟

Package .targets files.

At the moment when you develop an Umbraco package for Umbraco 9/10 you have to make sure you have a well formatted packagename.targets file in your package that copied all of your app_plugins files into the right place when a developer builds or publishes your package.

this on the whole is ok and it works, but its no ideal, it has some side effects and it can be confusing;

• You are writing files into the sites project with little or no say from the dev.
• The files get mysteriously wiped or overwritten when a clean build or rebuild is done.
• Get the target's wrong and you could easily loose a day figuring it out.

Razor class libraries

Razor class libraries have been developed mainly as a way of embedding razor views (and blazor etc) files into a dll so they can be packaged and used on a site without additional files floating around, and even just for this they are really cool.

Static web assets

Razor class libraries also contain another trick called static web assets. which let you embed any old file into your nuget package and get them consumed by the website that it is installed on.

with Static web assets you get a number of things:

• the files appear in the web project without actually being in the project (for development they are served from the nuget cache)
• the files are put in the right place at publication time (with a dotnet publish)
• the files can be overwritten by putting 'real' files in the locations they exit.

internally static web assets are actually using targets files, but those files are generated and managed by the build process so you don't have to worry about them