Content Pipeline Error: Item with the same key already added

1

I have a content pipeline extension that I’ve been working on. It takes information exported from Aseprite so I can do animations a bit easier. It was working, but I did the unthinkable and decided to refactor it a bit to make things a little simpler in the game code.

The problem I’m having is now, anytime I do a build in the content pipeline, it throws an error saying An item with the same key has already been added. The strange thing is it says this, not matter the content type it’s building. As long as my .dll is referenced in the pipeline tool, it does this.

For instance, with just my .dll referenced and only a spritefont file in the pipeline, it throws this error when building the spritefont file. The spritefont file has the correct importer/processor selected too. If i remove the reference to my .dll, it builds the spritefont fine.

I’m at a lose here, not even sure where to begin with figuring this out.
This was happening using the 3.6.0.1625 pipeline tool as well as the newer 3.7.0.1708 pipeline tool, so pretty sure it’s something dumb I’ve done on my end.

I have a solution with many projects in it, so I’ll try to provide the source code the best I can here. Here is a snapshot of the solution explorer with the files explained below highlighted.. One thing to note, the Psire.Asperite project is misnamed (aseprite spelled wrong), i just haven’t done the project renaming yet.

Psiren.ContentPipelineExtensions.AsepriteModel

Psiren.Asperite.ContentReaders

2

well, I seem to have resolved this. I’m not sure exactly why it fixes it, maybe someone can let me know. The processor using System.String as the TInput and TOuput, and the writer used System.String as the TInput. After looking at one of the MonoGame.Extended pipeline extensions for reference, I noticed that he uses a ProcessorResults class as a wrapper for the data to send to the writer.

So, i wrote a simple class, AsepriteModelProcessorResults, with one string property to store the json string produced from the processor, and used that as the TOuput on the processor and the TWrite on the writter. This fixed it.

While i’m glad this is fixed, I would love to know what exactly the issue was here.