Breaking Changes in MonoGame Content Pipeline Broke Custom Content Importer/Processor Handling

[uygary]

Description

There is a breaking change to how content importers and content processors are handled in MonoGame content pipeline, with the current preview build (MonoGame 3.8.5-preview.2).
This function is now deprecated, marked as obsolete, and it's throwing a NotSupportedException.

When attempting to use a custom ContentImporter and a custom ContentProcessor implementation, the new content builder calls into an obsolete method, instead of using the passed in instances, which in turn throws an exception.
Rgith now, there doesn't seem to be a way to use custom content importers or processors using what's available on the TiledMapTilesetImporter, TiledMapImporter, TiledMapTilesetProcessor and TiledMapProcessor in order to load Tiled maps, the content pipeline now breaks, failing to load Tiled maps.

Steps to Reproduce

Update MonoGame dependencies to 3.8.5-preview.2 in an existing project in order to use the new content build tool, or create a new solution using the MonoGame template via the dotnet tool: dotnet new mg2dmgcbstartkit

Then use this Builder example:

using Microsoft.Xna.Framework.Content.Pipeline;
using MonoGame.Extended.Content.Pipeline.Tiled;
using MonoGame.Framework.Content.Pipeline.Builder;

var contentCollectionArgs = new ContentBuilderParams()
{
    Mode = ContentBuilderMode.Builder,
    WorkingDirectory = $"{AppContext.BaseDirectory}../../../",
    SourceDirectory = "Assets",
    Platform = TargetPlatform.DesktopGL,
};
var builder = new BabyDashContentBuilder();

if (args is not null && args.Length > 0)
{
    builder.Run(args);
}
else
{
    builder.Run(contentCollectionArgs);
}

return builder.FailedToBuild > 0 ? -1 : 0;

public class CustomContentBuilder : ContentBuilder
{
    public override IContentCollection GetContentCollection()
    {
        var contentCollection = new ContentCollection();

        // include everything in the folder
        contentCollection.Include<WildcardRule>("*");

        var tilesetImporter = new TiledMapTilesetImporter();
        var tilesetProcessor = new TiledMapTilesetProcessor();
        var tiledMapImporter = new TiledMapImporter();
        var tiledMapProcessor = new TiledMapProcessor();

        // By default, all content will be imported from the Assets folder using the default importer for their file type.
        // Please add any custom content collection rules here.
        contentCollection.Include<WildcardRule>("Maps/Foo/*.tsx", tilesetImporter, tilesetProcessor);
        contentCollection.Include<WildcardRule>("Maps/Foo/*.tmx", tiledMapImporter, tiledMapProcessor);

        return contentCollection;
    }
}

Expected Behavior

Tilesets and maps should be imported without an issue as was the case with the MonoGame versions prior to the preview release.

Actual Behavior

Tiled tileset and map imports break in the content pipeline.

Configuration

• MonoGame 3.8.5-preview.2
• MonoGame.Extended 5.3.1
• MonoGame.Extended.Content.Pipeline 5.3.1
• .net 10.0
• Windows 11
• AMD64

Other Information

Original ticket I had opened on MonoGame repo is here, with the details.

[AristurtleDev]

Thanks for reporting this. Will hold on this for now until 3.8.5 is out of preview state as anything could change between now and it's release

[uygary]

Yeah, certainly makes sense.

[AristurtleDev]

@uygary could you try this with the new MonoGame.Extended 5.4.0-preview.1?

NuGets can be found at

https://www.nuget.org/packages/MonoGame.Extended/5.4.0-preview.1
https://www.nuget.org/packages/MonoGame.Extended.Content.Pipeline/5.4.0-preview.1

[uygary]

Hitting another wall due to more breaking changes now:

[E] FooBar.Content/Assets/Maps/Foo/Swamp.tsx: FooBar.Content/Assets/Maps/Foo/01.tmx: Content failed to build: System.ArgumentException: ExternalReference 'D:/ENT/FooBar/src/FooBar/FooBar.Content/Assets/Maps/Foo/Blah_1.xnb' must be in the root directory 'X:\T\FooBar\src\FooBar\FooBar.DesktopVK\bin\Debug\net10.0\win-x64\'

[uygary]

FYI: After fiddling with it for a while, I think it's correctly referring to Blah_1.xnb instead of Blah.xnb.

The new pipeline seems to build a lot of these files with the _1, _2, etc. suffixes. In fact, it builds some of them as both Blah.xnb and Blah_1.xnb files, with different contents. If I understand the contents of them correctly, the suffixed files are actual texture dependencies, and the files without those suffixes refer to those dependencies.

And when it complains about files not being at the root folder, it looks to me like it's actually referring to the path where it's looking for the files it builds. I mean the files are there, but not where it's looking for them.
One example is like this:
It expects the file to be in X:\T\FooBar\src\FooBar\FooBar.Content\bin\Content\ when the content is actually is in X:\T\FooBar\src\FooBar\FooBar.Content\bin\Content\Content\.

Unless sleep deprivation is making me read into all the console output and build artifacts wrong, it's a problem with where the files are output. It looks like it's outputting a redundant Content subfolder during build.