Nopipeline - saving you from Pipeline Tool.

Sup foxies. I present to you NoPipeline – a thing which makes you forget Pipeline Tool ever existed. It’s a free addon to Pipeline Tool, which automatically updates .mgcb config. Now all you have to do to add a new resource – is to just place it into a resource folder. No more hassle, no more UI bugs. It integrates into build process, so you don’t have to manually launch anything at all.

It’s also fully compatible with default Pipeline Tool. You can add or remove NoPipeline at any stage of development.

Read more and download:


@gn.fur Nice concept… will check it out!

Updated to v1.0.1.0

  • Added file association with *.npl
  • File names aren’t forced to lowercase anymore (caused Linux builds to not work)
  • Watch now works when adding a new file.

If you’ve already installed Nopipeline, I highly recommend updating, this build fixes a couple of pretty nasty bugs.

Nopipeline 1.1 is here! :0

  • Now you can specify references in the NPL config. Path to references support embedding environment variables.
  • Fixed various bugs related to relative paths.
  • Cleaned up the code. A lot.
1 Like

Nopipeline 2.0 is out. (:

  • No installer required! Nopipeline is now fully distributed via nuget. Reference Nopipeline.Task, add npl config and you’re done.
  • References now support wildcards.
  • Added root property, which enables linked files support.
  • Added sample project.

Nopipeline 2.1 o.o

  • ./ is now ignored if present in the root.
  • mgcb and npl configs are created automatically if missing.
  • Fixed faulty msbuild task.

Get it on Nuget (Nopipeline.Task) or download the package directly on github:

Nopipeline 2.1.3 : D

  • Fixed file watcher failing to detect deleted or renamed files.
  • Fixed npl not supporting usernames containing space character.
  • Fixed Linux compatibility.

Get it on Nuget (Nopipeline.Task) or download the package directly on github:

1 Like

Very nice. I don’t currently need it, but the Pipeline tool is a PITA so I’ll be revisiting this later.

Have to agree there…

I preferred it not being coupled…


Previous version had a critical bug which managed to slip through. Uploaded fixed version.
Download it on nuget or here.

Fixed failing to restore the npl config. ¯_(ツ)_/¯

Is it possible to use Nopipeline in a shared project? When creating a Monogame Shared Library Project it has a Content.mgcb file that gets built when building the main project.

I tried putting a npl file in the shared project and it didn’t seem to do anything.

In theory, it should have the same mechanisms as mgcb, check the project files themselves and see what’s the differences are. In practice, I highly recommend just using several mgcb and npl configs in each platform-specific project. I’ve done this in Monofoxe:

With Nopipeline this approach becomes actually feasible, less painless and requires a lot less magic.

The immediate difference I’m noticing is that I’m using shared projects (.shproj files). I don’t see any of those in your repo.

Should every project with .npl files reference Nopipeline? I don’t know all the details about how shared projects work, but as far as I can tell they don’t have references of their own, but are treated as having the same references as the project that they’re referenced by.

If it has mgcb config, then it should have Nopipeline reference.