Castle.Core DynamicProxy in 2018.3b12

Right now Castle.Core's DynamicProxy is not working when built to Windows standalone. It DOES work in the editor just fine, however a platform not supported exception is thrown when the build is run. Here is a link to the relevant part of Castle https://github.com/castleproject/Core/blob/master/src/Castle.Core/DynamicProxy/ModuleScope.cs#L346

PlatformNotSupportedException: Operation is not supported on this platform.

  at Castle.DynamicProxy.ModuleScope.CreateModule (System.Boolean signStrongName) [0x00018] in <23ac8904270149ebb9f6a73b9193828e>:0

  at Castle.DynamicProxy.ModuleScope.ObtainDynamicModuleWithWeakName () [0x00019] in <23ac8904270149ebb9f6a73b9193828e>:0

  at Castle.DynamicProxy.ModuleScope.ObtainDynamicModule (System.Boolean isStrongNamed) [0x0000a] in <23ac8904270149ebb9f6a73b9193828e>:0

  at Castle.DynamicProxy.ModuleScope.DefineType (System.Boolean inSignedModulePreferably, System.String name, System.Reflection.TypeAttributes flags) [0x00000] in <23ac8904270149ebb9f6a73b9193828e>:0

  at Castle.DynamicProxy.Generators.Emitters.ClassEmitter.CreateTypeBuilder (Castle.DynamicProxy.ModuleScope modulescope, System.String name, System.Type baseType, System.Collections.Generic.IEnumerable`1[T] interfaces, System.Reflection.TypeAttributes flags, System.Boolean forceUnsigned) [0x00012] in <23ac8904270149ebb9f6a73b9193828e>:0

  at Castle.DynamicProxy.Generators.Emitters.ClassEmitter..ctor (Castle.DynamicProxy.ModuleScope modulescope, System.String name, System.Type baseType, System.Collections.Generic.IEnumerable`1[T] interfaces, System.Reflection.TypeAttributes flags, System.Boolean forceUnsigned) [0x00000] in <23ac8904270149ebb9f6a73b9193828e>:0

  at Castle.DynamicProxy.Generators.Emitters.ClassEmitter..ctor (Castle.DynamicProxy.ModuleScope modulescope, System.String name, System.Type baseType, System.Collections.Generic.IEnumerable`1[T] interfaces) [0x00010] in <23ac8904270149ebb9f6a73b9193828e>:0

  at Castle.DynamicProxy.Generators.BaseProxyGenerator.BuildClassEmitter (System.String typeName, System.Type parentType, System.Collections.Generic.IEnumerable`1[T] interfaces) [0x0001e] in <23ac8904270149ebb9f6a73b9193828e>:0

  at Castle.DynamicProxy.Generators.InterfaceProxyWithTargetGenerator.Init (System.String typeName, Castle.DynamicProxy.Generators.Emitters.ClassEmitter& emitter, System.Type proxyTargetType, Castle.DynamicProxy.Generators.Emitters.SimpleAST.FieldReference& interceptorsField, System.Collections.Generic.IEnumerable`1[T] interfaces) [0x0000c] in <23ac8904270149ebb9f6a73b9193828e>:0

  at Castle.DynamicProxy.Generators.InterfaceProxyWithoutTargetGenerator.GenerateType (System.String typeName, System.Type proxyTargetType, System.Type[] interfaces, Castle.DynamicProxy.Generators.INamingScope namingScope) [0x00061] in <23ac8904270149ebb9f6a73b9193828e>:0

  at Castle.DynamicProxy.Generators.InterfaceProxyWithTargetGenerator+<>c__DisplayClass6_0.<GenerateCode>b__0 (System.String n, Castle.DynamicProxy.Generators.INamingScope s) [0x00000] in <23ac8904270149ebb9f6a73b9193828e>:0

  at Castle.DynamicProxy.Generators.BaseProxyGenerator.ObtainProxyType (Castle.DynamicProxy.Generators.CacheKey cacheKey, System.Func`3[T1,T2,TResult] factory) [0x0011b] in <23ac8904270149ebb9f6a73b9193828e>:0

  at Castle.DynamicProxy.Generators.InterfaceProxyWithTargetGenerator.GenerateCode (System.Type proxyTargetType, System.Type[] interfaces, Castle.DynamicProxy.ProxyGenerationOptions options) [0x00085] in <23ac8904270149ebb9f6a73b9193828e>:0

  at Castle.DynamicProxy.DefaultProxyBuilder.CreateInterfaceProxyTypeWithoutTarget (System.Type interfaceToProxy, System.Type[] additionalInterfacesToProxy, Castle.DynamicProxy.ProxyGenerationOptions options) [0x00026] in <23ac8904270149ebb9f6a73b9193828e>:0

  at Castle.DynamicProxy.ProxyGenerator.CreateInterfaceProxyTypeWithoutTarget (System.Type interfaceToProxy, System.Type[] additionalInterfacesToProxy, Castle.DynamicProxy.ProxyGenerationOptions options) [0x00006] in <23ac8904270149ebb9f6a73b9193828e>:0

  at Castle.DynamicProxy.ProxyGenerator.CreateInterfaceProxyWithoutTarget (System.Type interfaceToProxy, System.Type[] additionalInterfacesToProxy, Castle.DynamicProxy.ProxyGenerationOptions options, Castle.DynamicProxy.IInterceptor[] interceptors) [0x00052] in <23ac8904270149ebb9f6a73b9193828e>:0

  at Castle.DynamicProxy.ProxyGenerator.CreateInterfaceProxyWithoutTarget (System.Type interfaceToProxy, Castle.DynamicProxy.IInterceptor interceptor) [0x00000] in <23ac8904270149ebb9f6a73b9193828e>:0

  at Castle.DynamicProxy.ProxyGenerator.CreateInterfaceProxyWithoutTarget[TInterface] (Castle.DynamicProxy.IInterceptor interceptor) [0x00000] in <23ac8904270149ebb9f6a73b9193828e>:0 

I cannot generate builds and distribute them with Unity2018.3 because of this.

 

Same issue with a dependency called Fasterflect:

at Fasterflect.Emitter.BaseEmitter.CreateDynamicMethod (System.String name, System.Type targetType, System.Type returnType, System.Type[] paramTypes) [0x00017] in <3c126dd53ccd4fffb07bc1e577e11e58>:0

  at Fasterflect.Emitter.MemberSetEmitter.CreateDynamicMethod () [0x00010] in <3c126dd53ccd4fffb07bc1e577e11e58>:0

  at Fasterflect.Emitter.BaseEmitter.GetDelegate () [0x00014] in <3c126dd53ccd4fffb07bc1e577e11e58>:0 

Multiple dependencies not working when built to standalone windows is showstopping for me.

 

It may sound pedantic, but shouldn't you be telling this to the authors of those third party assets too? They should be the ones dealing with upgrading them for the new Unity version. Yes, the assets most likely don't work in the builds because of some change, but that doesn't mean that change is actually a bug.

Anyway, I feel you, most asset authors wait until a Unity version is out of Beta to upgrade so if your work depends on one of them you are basically stuck.

 

No, that is not how it works. I'm not going to go tell the Castle developers and Fasterflect developer that their valid .NET/C# code that executes just fine on standard .NET runtimes that they need to make changes or rewrite parts of their library to support the specialize case where Unity Technologies has a non-standard .NET runtime with parts that are unimplemented.

That is silly. These are not assets. These are libraries that are used daily in typical .NET development. These are libraries that other libraries depend on too. This has nothing to do with Unity3D asset developers.

 

I see, well, then let's just hope Unity tries to keep perfect parity so all random external libraries you find in the Internet always work out of the box...

 

Yes that's how libraries work... Unity is the exception here and Unity is the one that needs to make sure they're remaining compatible. Everything else is already compatible with each other...

 

Yes, that's how the .NET software ecosystem works. Platform not supported exceptions are rare but occur on some platforms. But on WINDOWS of all platforms, the main platform for .NET, you should not be encountering a not supported exception for a part of the runtime that many libraries depend on. Especially when it works in the Windows editor too.

Do you realize how damaging missing parts of the runtime is for the years of software written that depends on these sorts of functionality?

 

Sorry, I guess I didn't phrase that well. English is not my first language. I didn't mean it to sound with alternative meanings? Anyway, I accept I can't understand the magnitude of the issue well since I don't really use external libraries myself.

 

Yea, I am targeting netstandard 2.0. Many of my dependencies are netstandard. I'm not sure I'll be able to switch. While things like appdomain, which some of these libraries depend on, aren't implemented in netcore (https://github.com/dotnet/standard/issues/456) they should be on Mono/.NET. I was under the impression that Unity was still using .NET/Mono and not .NET Core.

Seems Castle has a feature flag for FEATURE_APPDOMAIN, I'll have to look to look closer into which version of Castle contains that. Fasterflect on the other hand is mostly unmaintained so that is going to be a whole other problem.

I really appreciate the response. But I can't tell if this is something intended, Windows standalone .NET Runtime missing support for what I am assuming is AppDomain or maybe DynamicMethod (can't tell with the callstack), or if this is something that will eventually be implemented for platforms that support .NET/Mono such as PC/Mac/Linux.

If I recall I originally upgraded to 2018 due to issues with netstandard assemblies in 2017. When I try to generate a build with net4x it just hangs, no information or errors.

 

When I try to generate a build with net4x the generated build just hangs when run, no information or errors. No real information to go on with what's wrong. The log file just stops so I'm abit stuck. Would take awhile to migrate away from Castle dynamicproxy since it's a dependency of a dependency.