Could not find ContentTypeReader Type


I have built my own library on top of MonoGame for stuff like TileMaps, Particles, etc…
All parts (TileMap,Particles,…) have their own Project and compile into .dlls.
After compiling I merge them all using ILMerge into a single .dll.

Now I reference this single dll in my game-project and everything seemed to work fine. Using TileMaps, Particles, etc.
Loading textures with the content-manager works perfectly fine.

BUT loading anything else with the content-manager(effects,spritefonts,…) results in the following Error:

{"Could not find ContentTypeReader Type. Please ensure the name of the Assembly that contains the Type matches the assembly in the full type name: Microsoft.Xna.Framework.Content.SpriteFontReader, MonoGame.Framework, Version=, Culture=neutral, PublicKeyToken=null (Microsoft.Xna.Framework.Content.SpriteFontReader, MonoGame.Framework)"}

I guess it somehow can’t find the classes for the content-readers, but why are textures working then?
Any idea on how to fix this?


Does it work without using ILMerge? It sounds like SpriteFontReader is getting stripped, even though we have code in ContentTypeReaderManager to stop the standard type readers from getting stripped.

Oh, right. So it would be something like ILMerge thinking the type is not used because instances are only created through reflection, thus stripping it?

Yeah I tried without ILMerge. Just referencing the single .dlls and monogame.
Compilation works fine. But when I start I get:
Additional information: The Windows-Runtime-Type 'Windows.ApplicationModel.Activation.ApplicationExecutionState' was not found.

Maybe my project-setup is wrong? Right now when adding a new Project I create a Monogame.DesktopGL Project, delete all the content and set the output-type to “Class Library”.

Edit: I found that when I add monogame as reference, no matter which .dll I selected, it always added the WIndows8-dll to the project. I now manually added the DesktopGL-dll via “Browse” and it seems to work. So seemingly ILMerge IS the problem. (Though referencing the wrong .dll is also a problem)

So any idea on how to use ILMerge to make it work? Currently I do t his:
"$(SolutionDir)Scripts\ILMerge.exe" /target:library /out:"$(SolutionDir)bin\$(ConfigurationName)\yasg.dll" "$(TargetDir)*.dll" /targetplatform:v4,C:\Windows\Microsoft.NET\Framework64\v4.0.30319 /wildcards /xmldocs /closed

@Finnhax Hello, I’m currently experiencing this issue. Did you ever end up finding a solution to get spritefonts working in a dll after using ILMerge? I’m trying to use ILMerge to merge all of the dlls my project depends on into a single dll and I’m getting the same error you describe above.

I know this is a little off-topic, but just in case you are struggeling to much with ILMerge, I can recommend different approaches fighting the classical problem of “DLL-Hell”.

  1. Embedding Assemblies in a ressource file and use a AssemblyResolver to find them (not that difficult)
  2. Using Assembly Probing in your app.config file (easy peasy lemon squeezy)

To 2:

<?xml version="1.0" encoding="utf-8" ?>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <!-- Add here your custom folders -->
      <probing privatePath="YourAssemblyFolder1; YourAssemblyFolder1\SubFolder" /> 

To 1:

Search for it by using your favorite search-engine and you will find many useful samples.

Just remember: ILMerge is the hardest way (when thinking about the long term issues you might encounter with a higher chance).

Anyway, this are just my 2 cents.

I tried using the approach of embedding assemblies in a resource file and it wasn’t working, which is why I tried to go the ILMerge route. But maybe I’m doing something wrong. Here’s what I’m doing:

Got all required dlls in the project’s root folder for simplicity while I try to sort this out.
Added those dlls to the project with ‘Build Action’ set to ‘Embedded Resource’ and ‘Copy to Output Directory’ set to ‘Do not copy’. This is what it looks like:

Then I added them as references to the project with ‘Copy local’ set to ‘false’ so that they aren’t copied to the output folder.

Finally I added this code to the static constructor of my ‘Program’ class, which is the entry point of the program.

    static Program()
        AppDomain.CurrentDomain.AssemblyResolve += new ResolveEventHandler(Resolver);

    static System.Reflection.Assembly Resolver(object sender, ResolveEventArgs args)
        Assembly a1 = Assembly.GetExecutingAssembly();
        Stream s = a1.GetManifestResourceStream(args.Name);
        byte[] block = new byte[s.Length];
        s.Read(block, 0, block.Length);
        Assembly a2 = Assembly.Load(block);
        return a2;

And whenever I try to run the program I get the following error:

Which is why I tried to go the ILMerge route, which does work as long as my scene doesn’t require a spritefont, because I get the error in the original post when I try to load one.

As a regular rule of life: start simple and learn something out of simplicity. Slowly start to grow bigger and find solutions to problems more easily.

For example: watching a youtube video

Alright, I managed to embed monogame and the other dlls inside my engine dll using the embedded resources method. When I compile my engine as an executable file and run it, everything works. But when I try to export it as a dll to be referenced in other projects I run into another issue. When I add the engine dll to a new game project and try to create a new game class derived from my main engine class, which itself is a subclass of the Monogame ‘Game’ class, I get an error message.

“The type ‘Game’ is defined in an assembly that is not referenced. You must add a reference to assembly 'MonoGame.Framework …”

So, even though the Monogame.Framework.dll is embedded as a resource in my engine. ll the game app can’t find it. When I merge the dlls using ILMerge the game works correctly referencing just the engine dll (with the previously described issue with the spritefonts). So I’ve hit a wall using both methods. I just wanted a way to reference just the engine dll when creating different game projects, instead of having to move over all of the dlls the engine uses. :confused:

Well, I didn’t really resolve it, because I started from scratch a few days later.
This time instead of having seperate projects for each engine-part I just used a single project with subfolders.
That way I don’t need IL-Merge

1 Like

It seems that you are not including the MonoGame.Framework into your engine namespace. This could be the problem for your derived projects to find the framework.

Either you are tinkering around with the assembly resolver or you reference the MonoGame.Framework in your derived project, which has also the advantage of upgrading the framework “on the fly”.

You can instantly test this by referencing the MonoGame.Framework in your derived project and see if it runs.

If you don’t want to include the MonoGame.Framework into your engine namespace then you should just reference it and let the MonoGame.Framework assembly come in differently (manually).

Yes, this is also ok if it works for you.

In my case this wouldn’t work out pretty well, because some parts of my engine containing editor specific stuff, which shouldn’t live in a compiled game project (this can be things like WindowsForms / WPF data or post processing stuff).

In the end the solution needs to fit your specific problem as there is not a single solution for everyone.

I personally like very simple solutions (like assembly probing) to solve complex problems. At least managing many dll’s can be a kind of a problem but they don’t need to be.

I’m happy if you found a solution whichs works right for you.