Contract Configurator Broke My Mod!

[nightingale]

The latest release of Contract Configurator (1.20.2 as of this writing) introduced some code that is causing some problems for other mods.  I realize in hindsight that I could've been more proactive in getting this out there, but better late than never.

There is a bug in Toolbar's integration code.  This is the code that the toolbar provides with the message to modders that says "hey, take this code and put it in your mod if you want to support toolbar".  It's a minor bug, and needs something very specific to cause it to fail.  The failure is on the check that says, "hey, is toolbar installed?".  So you don't need toolbar installed for this to fall over, just a mod that supports toolbar.

Now, what caused the bug to get exposed is the combination of the new difficulty settings screen in stock and the fact that I need to use it in a dynamic way in Contract Configurator.  I knew that the change in Contract Configurator exposed the bug in toolbar a while back (see here).  I looked at alternatives in Contract Configurator and went as far as to (briefly) consider changing stock code to avoid all this.  There just wasn't a good answer.  So I decided to move ahead, and do as much advance damage control as possible.  In hindsight, the post on the toolbar thread wasn't enough - and that's a mistake that I'm correcting now.

So if you see compatibility issues with a mod, then link them to this post.  Create a pull request based on the details below, and get the mod in question fixed (99% of mod authors will appreciate this).

Technical detail of the bug, and fix details for modders follows:

Spoiler

The following is the exception that happens in the older code.

[EXC 21:21:15.772] NotSupportedException: The invoked member is not supported in a dynamic module.
    System.Reflection.Emit.AssemblyBuilder.GetExportedTypes () (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.Reflection.Emit/AssemblyBuilder.cs:680)
    RSTUtils.ToolbarTypes+<>c.<getType>b__5_0 (.LoadedAssembly a)
    System.Linq.Enumerable+<CreateSelectManyIterator>c__Iterator12`2[AssemblyLoader+LoadedAssembly,System.Type].MoveNext ()
    System.Linq.Enumerable.Single[Type] (IEnumerable`1 source, System.Func`2 predicate, Fallback fallback)
    System.Linq.Enumerable.SingleOrDefault[Type] (IEnumerable`1 source, System.Func`2 predicate)
    RSTUtils.ToolbarTypes.getType (System.String name)
    RSTUtils.ToolbarManager.get_Instance ()
    RSTUtils.ToolbarManager.get_ToolbarAvailable ()

The reason it happens, is that I am using Reflection.Emit to create a class on the fly to be used by the stock Difficulty screen (the class needs to be dynamic, as it includes fields for each Contract Pack, and a contract pack is just config with no code to it).  Because of reasons, calling the GetExportedTypes() on a dynamic assembly (such as ones created using Reflection.Emit) will cause the above exception.

The fix just uses an alternate method to find the toolbar class.  The change in the toolbar wrapper is:

 		internal static Type getType(string name) {
 -			return AssemblyLoader.loadedAssemblies
 -				.SelectMany(a => a.assembly.GetExportedTypes())
 -				.SingleOrDefault(t => t.FullName == name);
 +			Type type = null;
 +			AssemblyLoader.loadedAssemblies.TypeOperation(t =>
 +			{
 +				if (t.FullName == name)
 +					type = t;
 +			});
 +			
 +			return type;
  		}

Or you can grab the updated toolbar file from here and merge it into your project (remembering to change the namespace).

 

[jbarry39]

Yup...same thing here pal.

Installed CC thinking i'm gonna do Historic Missions and stuff and like half 

my mods got starched!

In addition...it seemed VERY unstable.  Upon clicking Mission Control, when moving the mouse

the print/descriptions of the text would appear/disappear.

Install at your own peril!

[nightingale]

4 hours ago, jbarry39 said:

In addition...it seemed VERY unstable.  Upon clicking Mission Control, when moving the mouse

the print/descriptions of the text would appear/disappear.

That's a stock issue that is being looked at for 1.2.1.

[jbarry39]

Mind You it's a GREAT mod!  Love the Historic Missions!!!

Just bummed out that I can't use it

 

[jbarry39]

I also see that CC version 1.20.3 has been released 14hrs ago.

A little suspicious about using it...don't wan't all my mods to get trashed again!

[Shadriss]

1 hour ago, jbarry39 said:

I also see that CC version 1.20.3 has been released 14hrs ago.

A little suspicious about using it...don't wan't all my mods to get trashed again!

The problem isn't with CC per se... it's the error that he described above in concert with other mods pulling the original way. Either set of mods would work in isolation, it when both are installed and the code for Toolbar portion hasn't been updated that causes the conflict.

[jbarry39]

That's really odd...because I never had Toolbar installed.

[Superfluous J]

6 hours ago, jbarry39 said:

Upon clicking Mission Control, when moving the mouse

the print/descriptions of the text would appear/disappear.

Install at your own peril!

 

2 hours ago, nightingale said:

That's a stock issue that is being looked at for 1.2.1.

Yeah I have 2 installs, one with CC and one without. The above happens in the on withOUT CC. The one WITH CC does not have the problem.

[AlphaMensae]

3 hours ago, jbarry39 said:

That's really odd...because I never had Toolbar installed.

 

On 10/23/2016 at 10:43 PM, nightingale said:

 The failure is on the check that says, "hey, is toolbar installed?".  So you don't need toolbar installed for this to fall over, just a mod that supports toolbar.

You don't even need Toolbar installed to get the bug, just the query from a mod to see it it exists is enough to trigger the bug.

[Jashin]

So whose job is it to fix this? I haven't really understood if there is something wrong with the code in the Toolbar mod or if the others have to change the way they interact with it (sorry if I'm dumbing it down too much).

Right now, most Toolbar windows in my game are completely out of whack.

[nightingale]

4 hours ago, Jashin said:

So whose job is it to fix this? I haven't really understood if there is something wrong with the code in the Toolbar mod or if the others have to change the way they interact with it (sorry if I'm dumbing it down too much).

The responsibility lies with the mods that use toolbar.

4 hours ago, Jashin said:

Right now, most Toolbar windows in my game are completely out of whack.

Not sure what "out of whack" means, but this issue should cause anything between preventing mods from working to just preventing them from adding to the toolbar.  I can't really say more than that, simply because the issues caused are likely to be completely different for every mod, depending on how it sets up its toolbar.

[magico13]

1 hour ago, nightingale said:

The responsibility lies with the mods that use toolbar.

FYI, it's not just mods that use the toolbar mod. From what I understand it's any mod that uses the loadedAssemblies.SelectMany function for recognizing the presence of other mods (and accessing methods/fields on them through reflection). For KCT and StageRecovery that breaks far more than Toolbar support, it also impacted support for FMRS, RealChute, KSCSwitcher, Kerbal Konstructs, StageRecovery (in KCT), TestFlight, RemoteTech, CrewQueue (though the last three aren't really supported by me anymore though).

I realize that the toolbar wrapper is probably going to be the only source of trouble for most mods, but it's worth noting that thi is more than an issue for just toolbar.

[nightingale]

1 minute ago, magico13 said:

FYI, it's not just mods that use the toolbar mod. From what I understand it's any mod that uses the loadedAssemblies.SelectMany function for recognizing the presence of other mods (and accessing methods/fields on them through reflection). For KCT and StageRecovery that breaks far more than Toolbar support, it also impacted support for FMRS, RealChute, KSCSwitcher, Kerbal Konstructs, StageRecovery (in KCT), TestFlight, RemoteTech, CrewQueue (though the last three aren't really supported by me anymore though).

I realize that the toolbar wrapper is probably going to be the only source of trouble for most mods, but it's worth noting that thi is more than an issue for just toolbar.

More accurately - any mod that calls GetExportedTypes() on every assembly to search for a type (as opposed to other methods, such as searching for an assembly by name).

[gary.townsend]

Thank you Nightingale for at least trying to explain it to others, this make s a lot of sense once you take a moment to read and not knee jerk react. 

[nightingale]

Right, I've figured out another way to do things, which means this should no longer occur.  Props to everyone who did get their mods updated though (it's still a good idea - someone else could come along and do the same thing).

[linuxgurugamer]

Thank you for going the extra mile on this