SimpleInjector: 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?
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 17
Turns out this is some nasty incompatibility between
System.Net.Httpassemblies 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 theSystem.Net.Httpnamespace, such asHttpClient, from one to the other, this exception happens.To fix it, I’ve had to do a combination of things:
<ImplicitlyExpandNETStandardFacades>False</ImplicitlyExpandNETStandardFacades>in the .net Framework projects that reference the .net standard projects and have the cross boundary usages ofSystem.Net.HttpSystem.Net.Httpwhich does not exhibit the problem:So nothing at all to do with SI, but I appreciate the help!
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.
I pieced it together from a bunch of different threads, still not entirely confident on what the right thing to do is.
https://github.com/dotnet/sdk/issues/1647 (seems like a fix should be incoming for .net 4.7.2) https://github.com/dotnet/corefx/issues/25773 https://github.com/Microsoft/msbuild/issues/2527