File processing

Package	Release
Fp
Fp.Fs
Fp.Plus
Fp.Platforms.Nitro
Fp.Templates

Documentation | Samples

Fp is designed as a framework for implementing concise data format extractors, primarily for archive containers and 2D rasters.

Many utilities for working with primitive data (including endianness-dependent I/O) are provided. See the Samples for more.

Libraries

• Fp: Base file processing library
  • .NET Standard 2.0 / .NET 6.0
• Fp.Fs: Filesystem processing library
  • .NET Standard 2.0 / .NET 6.0
• Fp.Plus: Extension library (e.g. RGBA32 image (through ImageSharp) / PCM WAVE output)
  • .NET Standard 2.0 / .NET 6.0
• Fp.Platforms.Nitro: Nintendo DS file format integrations
  • .NET Standard 2.0 / .NET 6.0

Scripting

• fpx: Script execution program (thin wrapper of dotnet-script)
  • Requires .NET 6 SDK for execution
• Dereliction: Basic Avalonia GUI script editor / testing program
  • Requires .NET 6 SDK for execution

Details

Filesystem processors are a unit worker derived from Fp.Fs.FsProcessor or one of its descendants that are called to operate on each applicable (by default, based on extension) file path, optionally opening a stream and generating console output or file artifacts. If written to only use compatible APIs (e.g. working with the FileSystemSource APIs and not directly using System.IO.File etc.), processors can be used to work with synthetic filesystems (e.g. directly working on files in a zip file) and more generally be used to efficiently interact with any binary data regardless of source.

File format processors are a unit worker derived from Fp.FormatSingleProcessor, Fp.FormatMultiProcessor, or one of their descendants. They can be used to efficiently obtain converted data from individual files, or be wrapped with FormatSingleProcessorFsWrapper / FormatMultiProcessorFsWrapper to be used as a FsProcessor.

Programs intended to extract from a set of files / folders (recursively) to a destination can utilize the default FsProcessor.Run<T> function where T is a user-created processor class. All file I/O is managed by the library, the processor will be automatically fed input file paths and can opt to open these files / create new files (automatically placed in the output directory) via the Processor class APIs.

Processors can be designed to generate a System.Collections.Generic.IEnumerable<Fp.Data> where Data represents an arbitrary content result with an associated filename, such as Fp.Plus.Images.Rgba32Data for an RGBA 32-bit image, or Fp.BufferData<byte> for an arbitrary byte buffer. This can be a useful pattern for designing an arbitrary import scheme for software that needs to be able to work with new file types without unnecessary pipeline changes.