---
title: "Server-side registering of Package Manifest in Umbraco 14"
description: "Umbraco 14 packages are registered with umbraco-package.json files, but you can also register using C#. I'll show you!"
date: 2024-08-08
tags: ["umbraco"]
---

![Cover](/images/blog/serverside-registering-of-package-manifest-in-umbraco-14/cover.jpeg)

Previously in Umbraco, if you had a package you wanted to register without including frontend files, you could add the package manifest as an `IManifestFilter` and append it to the manifest filter collection using an `IComposer` like this:

```csharp
public class MyManifestFilter : IManifestFilter
{
	public void Filter(List<PackageManifest> manifests)
	{
		manifests.Add(new PackageManifest()
		{
			PackageName = "MyPackage"
		});
	}
}

public class MyComposer : IComposer
{
	public void Compose(IUmbracoBuilder builder)
	{
		builder.ManifestFilters().Append<ImageSharpRemoteImagesManifestFilter>();
	}
}

```

This would register "MyPackage" as a package in the Umbraco installation. With the new backoffice, everything backoffice-related, including package registration, should be handled in the frontend only.


## Umbraco 14 says it’s frontend only

In Umbraco 14, you now need to supply a static umbraco-package.json file in a folder inside the App_Plugins folder. This isn't a big deal, especially if your package also contains frontend components like property editors.

However, if your packages only contain backend code, you might not want to include static files.

Luckily, there's a new interface called `IManifestReader`, which reads and communicates all manifests in App_Plugins/*/umbraco-package.json to the backoffice. With some C#, you can use this interface to register your package in backend code.

> **Note:** If your package has frontend components, you should register it with the JSON file approach. You won't gain anything by doing it in C#.

The interface must implement a method called `ReadPackageManifestsAsync` that returns a list of `PackageManifest`s, similar to the old `IManifestFilter`.


## Example: Registering "MyPackage" in code

Here's an example of how to register "MyPackage" in C# in Umbraco 14:

```csharp
public class MyManifestReader : IManifestReader
{
	public async Task<IEnumerable<PackageManifest>> ReadPackageManifestsAsync()
	{
		return await Task.Run(() =>
		{
			return new List<PackageManifest>() {
				new PackageManifest()
				{
					Name = "MyPackage",
					Extensions = Array.Empty<object>()
				}
			};
		});
	}
}

public class MyComposer : IComposer
{
	public void Compose(IUmbracoBuilder builder)
	{
		builder.AddSingleton<IManifestReader, MyManifestReader>();
	}
}

```

As you can see, it's similar to before, with the main difference being that `Extensions` is required. Extensions is the way you register all your frontend components, like dashboards, property editors etc. If your package is containing only backend code, you don’t have any extensions.

## Using Package Manifests for Telemetry Data

Package manifests are also useful for showing up in Umbraco's telemetry data. If you set `AllowTelemetry` to true on your PackageManifest (`AllowPackageTelemetry` in the old `IManifestFilter`), data about the package will be included in Umbraco's telemetry data. This telemetry data is useful for getting an overview of which versions of Umbraco and packages are running in your projects.


## I just released a package that does this

So if you want to register your package from C#, it's still possible. But if you have frontend assets in your package, you shouldn't need to do it.

By the way, one of my packages that registers this way has just been released for Umbraco 14:

[![Remote Image Provider for ImageSharp](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7ub3niq61esdxm84c1d1.png 'Remote Image Provider for ImageSharp')](https://marketplace.umbraco.com/package/umbraco.community.imagesharpremoteimages)