Object.Extend<\/code> work seemed straight-forward at first. You can read my initial code in my original ObjectExtend post<\/a>. The problem started when I tried to chain two calls together: I immediately got a RuntimeBinderException<\/code>. Unfortunately, for a really good reason (the difficulty of discovering the right namespaces to search), the code responsible for runtime method binding doesn’t look for extension methods. That means that when the first call to .Extend<\/code> returns something marked as dynamic<\/code> (regardless of what actual type it returns), you can’t use any extension methods on the result. Attempting to call either .Extend<\/code> again or .Dump<\/code> (another common extension method in LINQPad) results in the dreaded RuntimeBinderException<\/code>.<\/p>\nThe usual usage of the dynamic<\/code> keyword is to let us return something like the ExpandoObject<\/code> type, like this:<\/p>\n\r\ndynamic ReturnSomething() {\r\n\treturn new ExpandoObject();\r\n}\r\n<\/pre>\nFortunately, the dynamic<\/code> keyword in C# essentially just tells the compiler to engage duck-typing mode – it doesn’t actually tell the run-time anything. So there’s nothing stopping us from doing this:<\/p>\n\r\ndynamic ReturnSomething() {\r\n\treturn new List<string>();\r\n}\r\n<\/pre>\nThe compiler (and your IDE) will allow you to try to call anything at all on the return value of ReturnSomething<\/code>, and hand everything off to the runtime binder. This means that you can’t use extension methods on anything returned by a method marked dynamic<\/code>, even if you actually return a regular non-dynamic type.<\/p>\n\r\ndynamic ReturnSomething() {\r\n\treturn new object();\r\n}\r\nReturnSomething().Dump();\r\n<\/pre>\nNope. Instant RuntimeBinderException<\/code>.<\/p>\nThere’s one situation which will give us exactly what we want – if we mark the .Extend<\/code> function as dynamic<\/code>, but the type we return has our Extend<\/code> method built right in to it. This means our IDE (LINQPad, in my case) will allow us to access any of the dynamic properties we build up on our types over successive calls to Extend<\/code>, and the runtime binder will be able to find the methods because they’re right on the type we return – we’re not relying on extension methods!<\/p>\nI initially thought I could create a subclass of ExpandoObject<\/code> with calls for Extend<\/code> and Dump<\/code>, but it turns out that not only is ExpandoObject<\/code> a sealed class, it’s also a bit special in other ways – so that was a no-go.<\/p>\nSo now the only problem we have is that we need to create types on the fly which contain functions for Extend<\/code> (and Dump<\/code>, for convenience), and also whatever properties we want to dynamically add – the union of all of the properties on the original object and the objects we want to extend it with. I looked into a few alternatives, and a good compromise was the Microsoft.CSharp.CSharpCodeProvider<\/code> – it allows me to dynamically assemble a syntax tree and get the framework to generate in-memory assemblies on-the-fly. The details are a little tedious, but it’s very possible to use this to create types on the fly – containing both the method calls we want for Dump<\/code> and Extend<\/code> as well as all of the properties we need. We can then instantiate our dynamically-created type and copy all of the values onto it. Our IDE will let us access our runtime-created properties and methods without compile-time errors, because our function is marked as dynamic – and the runtime binder can find all of the properties, as well as our .Extend<\/code> and .Dump<\/code> methods, because they’re actually on the type the runtime binder is looking at.<\/p>\nThe minimum viable code to do something useful with CSharpCodeProvider<\/code> looks something like this (note that this requires a couple of helpers you can find in the class linked below):<\/p>\n\r\nvar compileUnit = new CodeCompileUnit();\r\nvar nameSpace = new CodeNamespace("MyDynamicNamespace");\r\nvar classType = new CodeTypeDeclaration("MyNewType");\r\nclassType.Attributes = MemberAttributes.Public;\r\ncompileUnit.Namespaces.Add(nameSpace);\r\nnameSpace.Types.Add(classType);\r\nvar returnThree = new CodeMemberMethod {\r\n\tName = "ReturnThree",\r\n\tAttributes = MemberAttributes.Public,\r\n\tReturnType = new CodeTypeReference(typeof(int))\r\n};\r\nreturnThree.Statements.Add(new CodeMethodReturnStatement(new CodePrimitiveExpression(3)));\r\nclassType.Members.Add(returnThree);\r\nvar result = _cSharpCodeProvider.Value.CompileAssemblyFromDom(_compilerParameters.Value, compileUnit);\r\nvar compiledType = result.CompiledAssembly.GetTypes().Single();\r\nLINQPad.Extensions.Dump(((dynamic)Activator.CreateInstance(compiledType)).ReturnThree());\r\n<\/pre>\nThis is a very round-about way to output the number 3, but it works!
\n![\"PrintThree\"](\"http:\/\/www.nerdhold.com\/coder\/files\/2018\/04\/PrintThree.png\")
<\/a><\/p>\nI won’t reproduce the code here, but you can find all the details of the Object.Extend dynamic type creation in the CreateTypeUncached<\/code> function in ObjectExtend.cs<\/a>.<\/p>\nYou might notice the word ‘Uncached’ there. When I first tried this approach, it was horrifyingly slow – I was using Object.Extend in a Select<\/code> statement against a large IEnumerable<\/code>, and generating many identical types. Throwing a quick cache into the mix based on the name and type of all properties of the type we need vastly reduces the number of calls to the compiler service and brings performance up to a tolerable level.<\/p>\nWhile I have glossed over some details, hopefully this explanation will give readers some background information to aid in reading the code. Please feel free to reach out to me on Twitter<\/a> and let me know if parts of my explanation are hard to follow.<\/p>\n","protected":false},"excerpt":{"rendered":"I’ve had a few people ask me to explain how my C# Object.Extend implementation works – so here I am, going into more detail than I expected people would be interested in. Making Object.Extend work seemed straight-forward at first. You can read my initial code in my original ObjectExtend post. The problem started when I … Continue reading How my C# Object.Extend implementation works<\/span>