XmlHelper.FindType: MonoGame.Framework hates being searched through.

[0x0ade]

When running FEZMod on FEZ 1.11 through Steam, XmlHelper fails finding types in the MonoGame framework, making XmlHelper useless for basically anything. Hopefully "uh. uh duh" (just waiting) will fix it automatically.

(ignore FezCorruption for now; that's FEZ.Secret.mm)

(22:30:56.840) [FEZMod] Failed searching a type in XmlHelper's FindType.
(22:30:56.841) [FEZMod] Assembly: MonoGame.Framework
(22:30:56.842) [FEZMod] The classes in the module cannot be loaded.
(22:30:56.908) [FEZMod] Failed searching a type in XmlHelper's FindType.
(22:30:56.909) [FEZMod] Assembly: MonoGame.Framework
(22:30:56.909) [FEZMod] The classes in the module cannot be loaded.
(22:30:56.927) [Unhandled Exception] System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.NullReferenceException: Object reference not set to an instance of an object
  at FezGame.Components.CorruptionHost.ProcessLevelData (FezEngine.Structure.Level levelData) [0x00000] in <filename unknown>:0 
  at FezGame.CorruptionMod.FezCorruption.ProcessLevelData (FezEngine.Structure.Level levelData) [0x00000] in <filename unknown>:0 
  at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&)
  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 
  --- End of inner exception stack trace ---
  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 
  at System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) [0x00000] in <filename unknown>:0 
  at FezGame.Mod.FEZMod.CallInEachModule (System.String methodName, System.Object[] args) [0x00000] in <filename unknown>:0 
  at FezGame.Mod.FEZMod.ProcessLevelData (FezEngine.Structure.Level levelData) [0x00000] in <filename unknown>:0 
  at FezGame.Services.GameLevelManager.Load (System.String levelName) [0x00000] in <filename unknown>:0 
  at FezGame.Services.GameLevelManager.ChangeLevel (System.String levelName) [0x00000] in <filename unknown>:0 
  at FezGame.Components.Actions.EnterDoor.DoLoad (Boolean dummy) [0x00000] in <filename unknown>:0 
  at FezEngine.Tools.Worker`1[System.Boolean].Act () [0x00000] in <filename unknown>:0 
  at FezEngine.Tools.PersistentThread.DoActualWork () [0x00000] in <filename unknown>:0 
  at Common.Logger.Try (System.Action action) [0x00000] in <filename unknown>:0 

[0x0ade]

After some debugging, it turns out:

Could not load type 'MonoGame.Framework.MonoLive.MonoLive' from assembly 'MonoGame.Framework, Version=3.0.1.0, Culture=neutral, PublicKeyToken=null'.

The FEZ-SDL2 branch of FNA contains a copy of it here. It contains a reference to System.Web.Services, which is not included in the Steam version. This already caused issues, namely #1.

I am not able to find MonoLive in the official MonoGame repository, nor in the master branch of FNA, which means there is a great chance "Uh. Uh Duh" could fix it, but I still need confirmation. It still is possible for MonoGame / FNA types other than MonoLive to have references to assemblies not existing in MonoKickstart.

[0x0ade]

Copying System.Web.dll and System.Web.Services.dll into the Steam FEZ directory as workaround is now confirmed.

(SIDENOTE: Why am I commenting my own issues?!.. well, maybe if someone finds this: Hi!)

[0x0ade]

Got confirmation that "uh. uh duh" will fix this issue and other issues with assemblies not found that may occur. Supporting FEZMod via MonoKickstart in versions not affected by "uh. uh duh" may become harder, but that would generally only be 1.07 (unless the speedrun community creates a new category for "uh. uh duh"), which is being run outside of Steam (MonoKickstart) anyway.

Ways to fix this issue in versions not affected by "uh. uh duh":

• delivering System.Web.Services (confirmed as workaround; causes new unmet dependencies; licensing unknown)
• delivering a patched version of MonoGame-SDL2 (definitely killing Ethan's Steam PS4 controller beta and "uh. uh duh" support; licensing unknown)
• patching MonoLive dynamically (could kill "uh. uh duh" support due to the differences; could kill everything knowing my patching skills)