ExecutionEngineException in RegisterWebApiControllers

This may have nothing to do with Simple Injector and something we’re doing entirely wrong, but I am unable to troubleshoot this any further and was wondering if you could help.

Almost every time we build, and IIS reloads all assemblies, we get a crash in w3wp. Debugging always takes us to this line in one of our web apps’ Global.asax:

container.RegisterWebApiControllers(GlobalConfiguration.Configuration);

Here’s what happens before that line for context:

var container = new Container();
container.Options.DefaultScopedLifestyle = new AsyncScopedLifestyle();
container.Options.PropertySelectionBehavior = new InjectPropertySelectionBehavior();

#if DEBUG
// tried adding this to make the exception go away, but it did not work
container.Options.EnableDynamicAssemblyCompilation = false;
#endif

// this enumerates all our dependencies and registers them.
var registry = new Registry();
registry.All(container);

container.RegisterMvcControllers(Assembly.GetExecutingAssembly());
container.RegisterWebApiControllers(GlobalConfiguration.Configuration);

This only happens on dev machines, not Production, thankfully. But it’s super annoying as it dings productivity.

Anecdotally, it started happening when we started converting some our of assemblies to .NET Standard 2.0 from .NET Framework. Our solution is now a mix of .NET 4.7.1 and .NET Standard 2.0 assemblies.

Do you have any suggestions on how we could get to the bottom of this?

[mscrivo]

Turns out this is some nasty incompatibility between System.Net.Http assemblies in .net standard 2.0 and .net framework 4.7.1. If you have a .net 4.7.1 web project calling into a .net standard assembly and you pass objects from the System.Net.Http namespace, such as HttpClient, from one to the other, this exception happens.

To fix it, I’ve had to do a combination of things:

1. Set <ImplicitlyExpandNETStandardFacades>False</ImplicitlyExpandNETStandardFacades> in the .net Framework projects that reference the .net standard projects and have the cross boundary usages of System.Net.Http
2. Force the web projects to use an older version of System.Net.Http which does not exhibit the problem:

<dependentAssembly>
  <assemblyIdentity name="System.Net.Http" publicKeyToken="B03F5F7F11D50A3A" culture="neutral"/>
  <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.0.0.0"/>
</dependentAssembly>

So nothing at all to do with SI, but I appreciate the help!

[mscrivo]

Confirmation that the issue is real and that it should be fixed in the VS 2017 15.6 tooling: https://github.com/dotnet/sdk/pull/1712#issuecomment-363900651 and then the above workaround should no longer be needed.