In my previous post , i introduced a basic proxy that intercepts methods. But what is missing in the proxy is that it does not consider method arguments and can not handle return types. In this post, i will enhance the proxy to support exactly those.

First of all, i modified the IIntercept.Intercept() to accept IInvocaiton interface. The interface is pretty simple and it consists of an arguments array and a method that will be used to set the return value from interceptor.

  1. /// <summary>
  2.     /// Contains Invocation details.
  3.     /// </summary>
  4.     public interface IInvocation
  5.     {
  6.         /// <summary>
  7.         /// Gets the invocation arguments.
  8.         /// </summary>
  9.         object[] Arguments { get; }
  10.         /// <summary>
  11.         /// Sets the return value.
  12.         /// </summary>
  13.         /// <param name="value"></param>
  14.         void SetReturn(object value);
  15.     }

 

Internally, the interface is implemented with a class named MethodInovcation , where the arguments  and return type is passed through the constructor. As, arguments will be passed dynamically during method call, I first declared a  LocalBuilder that will actually take the arguments and wrap it around an array of objects which will be then passed to the constructor. Therefore, i created an extension method that will emit the necessary IL from method’s argument types.

 

  1. LocalBuilder args = ilGenerator.DeclareLocal(typeof(object[]));
  2.  
  3. ilGenerator.Emit(OpCodes.Ldc_I4_S, parameterTypes.Length);
  4. ilGenerator.Emit(OpCodes.Newarr, typeof(object));
  5. ilGenerator.Emit(OpCodes.Stloc, args);
  6.  
  7. if (parameterTypes.Length > 0)
  8. {
  9.     ilGenerator.Emit(OpCodes.Ldloc, args);
  10.  
  11.     for (int index = 0; index < parameterTypes.Length; index++)
  12.     {
  13.         ilGenerator.Emit(OpCodes.Ldc_I4_S, index);
  14.         ilGenerator.Emit(OpCodes.Ldarg, index + 1);
  15.  
  16.         Type parameterType = parameterTypes[index];
  17.  
  18.         if (parameterType.IsValueType || parameterType.IsGenericParameter)
  19.             ilGenerator.Emit(OpCodes.Box, parameterType);
  20.  
  21.         ilGenerator.Emit(OpCodes.Stelem_Ref);
  22.         ilGenerator.Emit(OpCodes.Ldloc, args);
  23.     }
  24.  
  25.     ilGenerator.Emit(OpCodes.Stloc, args);
  26. }
  

The OpCodes.NewArray instruction declares an array from the target with the length pushed on the top of evaluation(EV) stack. The most interesting part in this code is how  to take an argument and assign that to our array . OpCodes.Stelem_Ref actually assigns the value from the top of evaluation stack to the index that is mentioned through Opcodes.Ldc_I4_S where OpCodes.Larg [ 1 .. n ] pushes the argument to the top of EV stack.Outside the declaring of LocalBuilder through extension looks like:

  1. LocalBuilder locParameters = ilGenerator.DeclareParameters(paramTypes);

Here, we also need to declare a variable that will contain the instance of MethodInvocation

  1. LocalBuilder locMethodInvocation = ilGenerator.DeclareLocal(typeof (MethodInvocation));

Just before Intereptor.Intercept() is called (Let’s assume it from previous post), the following code is added.

  1. ilGenerator.Emit(OpCodes.Ldloc, locParameters);
  2. ilGenerator.Emit(OpCodes.Ldtoken, methodInfo.ReturnType);
  3. ilGenerator.EmitCall(OpCodes.Call, typeof(Type).GetMethod("GetTypeFromHandle"), null);
  4. ilGenerator.Emit(OpCodes.Newobj, typeof(MethodInvocation).GetConstructor( new []
  5. {
  6.   typeof(object[]), typeof(Type)
  7. }));
  8. ilGenerator.Emit(OpCodes.Stloc, locMethodInvocation);
  9. ilGenerator.Emit(OpCodes.Ldloc, locMethodInvocation);

 

Another interesting part is how we dynamically pass the method’s return value from interceptor. OpCodes.Ldtoken loads the type’s token from which by calling GetTypeFromHandle  the type is resolved in runtime and passed to the constructor.If you ever used an IL dissembler to look under the hood, you find it pretty common. Once, the extra lines are added to existing basic proxy , its time to check if things are doing just fine. To simplify, method will be called with an integer which will be returned by the interceptor.

  1. var proxy = new Proxy(typeof(TestClass));
  2.             var test = (TestClass) proxy.Create(new BasicInterceptor());
  3.  
  4.             int result = test.TestCall(1);
  5.  
  6.             if (result != 1)
  7.                 throw new Exception("result should equal 1");

Thus, the existing basic interceptor will covert into following :

  1. public class BasicInterceptor : IInterceptor
  2.     {
  3.         public void Intercept(IInvocation invocation)
  4.         {
  5.             System.Console.WriteLine("Intercepted");
  6.  
  7.             invocation.SetReturn(invocation.Arguments[0]);
  8.         }
  9.     }

We are setting the return from the argument that is passed in. As previously the MethodInvocation is assigned to a local variable,after the interception the value is get and unboxed(value type/enum should be unboxed from object).

  1. if (methodInfo.ReturnType != typeof(void))
  2. {
  3.     ilGenerator.Emit(OpCodes.Ldloc, locMethodInvocation);
  4.     ilGenerator.Emit(OpCodes.Callvirt, typeof(MethodInvocation).GetMethod("get_ReturnValue"));
  5.  
  6.     if (methodInfo.ReturnType.IsValueType ||
  7.         methodInfo.ReturnType.IsEnum)
  8.     {
  9.         ilGenerator.Emit(OpCodes.Unbox, methodInfo.ReturnType);
  10.         ilGenerator.Emit(OpCodes.Ldobj, methodInfo.ReturnType);
  11.     }
  12. }

The snippet is placed just before OpCodes.Ret. The OpCodes.Callvirt calls the ReturnValue property from MehodInvocation where the value is set and pushes on the top of EV stack. OpCodes.Ret returns with whatever the value is on the top of EV stack. The top has to be empty for void calls therefore an extra check is added.

Also, for value types we just can’t put null on EV stack, we will definitely end up with an “JIT encountered and internal limitation” error. Therefore, return value in MethodInvocation should go through the following check which is equivalent to default(value) call.

  1. if (returnValue == null && returnType.IsValueType)
  2. {
  3.     returnValue = Activator.CreateInstance(returnType);
  4. }

 

Finally, there are plenty of things that are missing in the proxy comparing to real ones but gives out a good example for playing with MSIL. The updated proxy can be downloaded from here .

 

Happy coding.

In this post, i am going to show how you can write your own proxy for delegating calls. This just shows a way how you can handle it on your own but for complex interceptions its always wise to use alpha/beta/tested solutions. The post is more of an under the hood or aims to solve simple interception tasks where you might not need a full featured dynamic proxy or can be useful in building something that requires similar techniques which can move you further.

Let’s start by considering a simple class

  1. public class TestClass
  2. {
  3.     public virtual void TestCall()
  4.     {
  5.         throw new Exception("Failed.");
  6.     }
  7. }

Here, during the creation of proxy i will hook the method with an interceptor that will alternate the execution process from original code. At a glace, our interceptor looks like:

  1. public interface IInterceptor
  2. {
  3.     void Intercept();
  4. }

As it shows, we are going to do a fairly basic implementation.To start, let’s create an implementation on it named BasicInterceptor where inside the Intercept call it just prints a line.

  1. public class BasicInterceptor : IInterceptor
  2. {
  3.     public void Intercept()
  4.     {
  5.         System.Console.WriteLine("Intercepted");
  6.     }
  7. }

Once, we are done with our proxy the result code will look something like below:

  1. var proxy = new Proxy(typeof(TestClass));
  2. var test = (TestClass) proxy.Create(new BasicInterceptor());
  3.  
  4. test.TestCall();

And the above test.TestCall() call Instead of throwing an exception, it will print our expected line. We can here see that I first created the proxy with the given type/class then during the instantiation i hooked that up with our interceptor. Hence, on my first step I created a class deriving from the specified type and  expanded its constructor(s) to take an IInterceptor implementation as parameter.

Accordingly, I first created a TypeBuilder instance from System.Refleciton.Emit which is pretty much common in all kind and that looks like:

  1. AssemblyName assemblyName = new AssemblyName("BasicProxy");
  2. AssemblyBuilder createdAssembly =  AppDomain.CurrentDomain.DefineDynamicAssembly(assemblyName, AssemblyBuilderAccess.Run);
  3. // define module
  4. this.moduleBuilder = createdAssembly.DefineDynamicModule(assemblyName.Name);

That is followed by:

  1. this.typeBuilder =
  2.     this.moduleBuilder.DefineType(target.FullName, TypeAttributes.Class | TypeAttributes.Public, target);

In the proxy , I defined a field named “interceptor” that will be assigned with the passed-in user-defined implementation.

  1. this.fldInterceptor = this.typeBuilder.DefineField("interceptor", typeof (IInterceptor), FieldAttributes.Private);

Now, for each constructor let’s expand it to have IInterceptor as first argument, call the corresponding base and set it to our defined field.

  1.  Type[] parameters = new Type[1];
  2.  
  3.  ParameterInfo[] parameterInfos = constructor.GetParameters();
  4.  parameters = new Type[parameterInfos.Length + 1];
  5.  
  6.  parameters[0] = typeof(IInterceptor);
  7.  
  8.  
  9.  for (int index = 1; index < parameterInfos.Length; index++)
  10.  {
  11.      parameters[index] = parameterInfos[index].ParameterType;
  12.  }
  13.  
  14.  ConstructorBuilder constructorBuilder =
  15.      typeBuilder.DefineConstructor(MethodAttributes.Public, CallingConventions.Standard, parameters);
  16.  ILGenerator generator = constructorBuilder.GetILGenerator();
  17.  
  18.  
  19.  
  20.  generator.Emit(OpCodes.Ldarg_0);
  21.  
  22.  for (int index = 1; index < parameters.Length; index++)
  23.  {
  24.      generator.Emit(OpCodes.Ldarg, index + 1);
  25.  }
  26.  
  27.  generator.Emit(OpCodes.Call, constructor);
  28.  
  29.  generator.Emit(OpCodes.Ldarg_0);
  30.  generator.Emit(OpCodes.Ldarg_1);
  31.  generator.Emit(OpCodes.Stfld, fldInterceptor);
  32.  generator.Emit(OpCodes.Ret);

 

Tip 1 : OpCodes.Ldarg_0 is like “this” context, which is not needed for static calls. If your are calling a field of the class or referring method arguments, always start with LdArgs_0 or you might end up with “JIT encountered an internal limitation” error.

Tip 2: In MSIL every method must terminate with OpCodes.Ret regardless its void or not. The difference between void and non-void calls is that the top of evaluation stack is not empty.

Now, as we set it up , we need to hook the interceptor in each method that is marked as virtual. First, let’s create the target method attribute :

  1. const MethodAttributes targetMethodAttributes =
  2.     MethodAttributes.Public | MethodAttributes.Virtual | MethodAttributes.HideBySig;

Next, for each method that is not final hook the IInterceptor.Intercept() call.

  1. if (methodInfo.IsVirtual)
  2. {
  3.     Type[] paramTypes = GetParameterTypes(methodInfo.GetParameters());
  4.  
  5.     MethodBuilder methodBuilder =
  6.         typeBuilder.DefineMethod(methodInfo.Name,targetMethodAttributes, methodInfo.ReturnType, paramTypes);
  7.  
  8.     ILGenerator ilGenerator = methodBuilder.GetILGenerator();
  9.  
  10.     ilGenerator.Emit(OpCodes.Ldarg_0);
  11.     ilGenerator.Emit(OpCodes.Ldfld, fldInterceptor);
  12.     ilGenerator.Emit(OpCodes.Callvirt, typeof(IInterceptor).GetMethod("Intercept"));
  13.  
  14.     ilGenerator.Emit(OpCodes.Ret);
  15. }

 

Again, before loading the interceptor field on to the evaluation stack , I used Ldarg_0 or “this” equivalent . If you notice, you will see that I have used OpCodes.Callvirt instead of OpCodes.Call. This will actually call the base method rather the implemented. This difference is important if you need to distinguish between base and implemented calls. Unless otherwise, it is better to go with OpCodes.Callvirt that will do the work for you if “base” is something not in your consideration.

Finally, you need to create the type and instance that will be initiated by Proxy.Create() call.

  1. Type proxy = this.typeBuilder.CreateType();
  2. return Activator.CreateInstance(proxy, args);

That’s it, we ended up with a simple proxy. In the next post, i will enhance it with parameters consideration and show how to handle return value from proxy. You can download the example proxy implementation from here.

Happy new year !!

Yesterday , i was reading Clean Code by Uncle Bob. While i was doing so , i came across a line that really stuck my thought patterns and i would like to share it with my readers as well.

The line looks something like, provided that there is a shape factory that will be implemented by concrete classes.

“What should you name them? IShapeFactory and
ShapeFactory? I prefer to leave interfaces unadorned. The preceding I, so common in
today’s legacy wads, is a distraction at best and too much information at worst

....

So if I must encode either the interface or the implementation, I choose
the implementation. Calling it ShapeFactoryImp, or even the hideous CShapeFactory, is preferable
to encoding the interface.”

 

This is true, in a sense today even our popular refactoring tools [there are not much, so you can easily figure out] when typed, precedes the interface with “I” word. And if we look though all the open source foundries, we will  see this here and there with no exception. Even honestly, i encode interfaces with “I” word, but technically it would be much better if we have a structure like

Shapes.Abstractions

| ShapeFactory

CSharpShapeFactory

 

After, reading that i came to realization that we should abandon this “I” encoding for interfaces that is going on decades to devs after devs. There should be a  “General coding guidelines” which should include it and FxCorp should mark it as invalid during code analysis.

Now, did i say something wrong , enlighten me, why we still need to encode our inferface, when our modern compiler are smarter enough to do it for us. I guess we are way too ahead from the days of integer based type encodings , aren't we ?

 

[Edit : This is true that  starting an interface with “I” has become more of a convention today. [SA1302: InterfaceNamesMustBeginWithI]. There are numerous project that follows it even i don't remember, i wrote one without it, at the same time the words at the book still worth thinking along with meaningful names as stated [From book] “I don’t want my users knowing that I’m handing them an interface. I just want them to know that it’s a ShapeFactory.”  Also, there are comments like, “I like “I”  because i want to know that its an interface, but question remains what productivity it will really provide?. Finally, convention is important to make us feel right at  home  but its not bad to discuss on other options that are forwarded by an industry expert, i mean there must be a reason.]

[Edit: The title should rather be why you should use “I” in your interface just because it’s a convention or you are used to it, what if you don’t use it , is there other options and are they worthy ? ]

Shout it

In my previous post , i mentioned about configuring Team build along with XUnit without installing anything on the build machine. This is sometimes useful as the build machine is miles away and is shared among other projects  and you don’t want to mess things up installing your stuffs.

Now, inside the TeamBuildTypes folder you can add your referenced dlls which you can use in your MSBuild target file to do automated test, which is on the other hand is referenced in TFSBuild.Proj file.

Now, It’s fine, but let’s say i want to organize my folders a little bit and occasionally want to drop the docs along with current build  from the source or any other folder that is necessary. To do so, we can visually customize it from Builds –> My Build –> Edit Build Definition –> Workspaces.

 

BuildWorkspace

 

Here, MyRoot is the root in my TFS setup where MyFolder is the one under which i have CodeBase, Build, Help , etc. By default, as sources get into a temp folder before the build starts , all the files from solution directory will be get and is entered under workspace folders automatically as you select your project file.  But if you want to get a Help file or reference assembly , in this case  XUnit MsBuild dlls then you have to specify it in this wizard, if you don’t want to have them under TeamBuildTypes/MyDefinationName folder.

Finally, from the previous XUniBuild.Targets our reference path will change like:

   1:    <UsingTask  AssemblyFile="$(SolutionRoot)\MyFolder\Build\xunit.runner.msbuild.dll"
   2:     TaskName="Xunit.Runner.MSBuild.xunit"/>
 
Or copy docs from
 
   1:  <Copy SourceFiles="$(SolutionRoot)\MyFolder\Help\MyDoc.docx" DestinationFiles="$(OutDir)\Docs\MyDoc.docx" /> 

 

Here , $(SolutionRoot) is the temp folder where items to be get according to the  workspace setup, where you can add/ modify items as you want and you can also see how its going from BuildLog that is dropped after each build to the root of your drop folder.

 

If you missed the previous post , here it is again:

http://weblogs.asp.net/mehfuzh/archive/2009/08/25/configuring-team-build-using-xunit.aspx

 

Hope that helps

Shout it

Recently, while i was setting up TFS build [to enable CI] for a project at Telerik that i am currently working on, i came across configuring it up with XUnit for doing automated tests every time someone checks-in source code after the build process is complete using the Xunit MsBuild task and additionally it will print the build steps so that developer knows what’s the issue.

Now, to layout a little bit of background. When you setup a “New build Definition” from Team Explorer – > Builds . TFS actually drops a  TFSBuild.proj under  “$/ProjectName/TeamBuidTypes/BuildDefinationName/” folder . This is nothing but a regular MSBuild file that defines how and where your project should be built and dropped and how it will be tested.

image

TFS gives out of the box support for VSTests , but for other types you need to do a little bit of configuration.When you do a check-in[If build process is setup to fire for each check-in],first TFS does a GET operation from /TeamBuildTypes/BuildDefinationName/ and after that it starts executing as things are defined in TFSBuild.proj. In the pasted Team explorer snap you can see that i have added a target file named “XunitBuild.targets”. It is referenced in TFSBuild.proj  somewhere above the <itemGroup> like

   1: <Import Project="$(MSBuildProjectDirectory)\XUnitBuild.targets" />

To use xunit task we need to include the following two assemblies in same folder with TFSBuild.proj.

  • xunit.runner.msbuild.dll
  • xunit.runner.utiliy.dll

 

Inside XUnitBuild.targets, first of all we need to reference the task. Just to mention that assembly file path will be preceded by a folder path where TFSBuild.proj is stored though GET operation.

   1: <UsingTask  AssemblyFile="xunit.runner.msbuild.dll"
   2:    TaskName="Xunit.Runner.MSBuild.xunit"/>

Next, we need to hook the task under specific target that will be invoked by TFS automatically. TFS has some predefined targets that are fired at different steps of the build process, we can hook them to perform some custom tasks before, during or after each step is completed.

Some of the targets are :

  • AfterCompile
  • BeforeTest
  • CoreTest
  • AfterTest
  • AfterDropBuild

You can get the full list from MSDN but i would rather leave it up to you as it is not the main topic here. Moving forward, i have hooked CoreTest Target [ set Name=”CoreTest”]. Inside it, i created a build step that will print if tests are successful or failed depending on the result returned by xunit task.

   1: <BuildStep
   2:            TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
   3:            BuildUri="$(BuildUri)"
   4:            Message="Preparing to test...">
   5:       <Output TaskParameter="Id" PropertyName="StepId" />
   6:     </BuildStep>

On first run BuildStep task will produce an Id that will be stored in a property which will be used later to print test status. 

   1: <xunit ContinueOnError="true" Assembly="$(OutDir)\Sample.Tests.dll" Verbose="true">
   2:       <Output TaskParameter="ExitCode" PropertyName="Result" />
   3: </xunit>

Executing xunit task requires the assembly path for tests to perform on,  additionally you can specify it to be verbose and finally can store the return code in a property for further checks. Here, i have also specified “ContinueOnError=true” as for any failure, things will be handled manually.

   1: <BuildStep Condition="'$(Result)'=='0'" TeamFoundationServerUrl="$(TeamFoundationServerUrl)" 
   2:              BuildUri="$(BuildUri)" Id="$(StepId)" Status="Succeeded" Message="Test succeeded." />
   3:   <BuildStep Condition="'$(Result)'!='0'" TeamFoundationServerUrl="$(TeamFoundationServerUrl)" 
   4:              BuildUri="$(BuildUri)" Id="$(StepId)"  Status="Failed"  Message="Test Failed." />
   5:  
   6:   <Error Condition="'$(Result)'!='0'" Text="Test failed."/>

Above two BuildStep tasks  will print test status depending on the result set by xunit task for previously created step and followed by Error task will fail the build for same.  Finally, when we will be expanding the build explorer, list will contain the custom step where build status will be determined from the error condition.

image

That’s it and here goes the target file XUnitBuild.zip . I actually binged it out and covered all together in one place so that it saves a little time of yours so feel free to suggest anything that comes to your mind.

Enjoy !!!

Shout it
Now , it happens that you go to McDonalds website and order an item for you. It could happen that price of the menu changed or new one comes to the menu. Now, generally it can happen that admin can go though wizard and loads of textboxes or dropdowns to make the changes or he/she can just write as if he/she is writing in some text editor and everything else is taken care of on behalf. Textual DSL is a powerful tool that might become the future of how we communicate to computer systems. Well, things are not that easy to convert human language to machine readable forms completely but its not bad to dream for the best :-).
 
In this post, i will show how you can change items using  M and then bind it to a data grid using LINQ query. I will do it using sample data that shows price menu for Mc burgers.
 
Our first step is to define a constant that holds the M value format.
 
   1: const string MGraphCode = @"Burgers
   2: {   
   3:    { Code=""DCB001"",Name=""Double Cheese Burger"",Quantity=1,Price=5},
   4:    { Code=""Mc001"",Name=""Mc Chicken"",Quantity=1,Price=4}
   5: }"; 

Next, you need to load the grammar using the QueryContext :

   1: var mcContext = QueryContext.Instance.Load(MGraphCode);

And, finally need to bind it to a data grid,

   1: gridView1.DataSource = mcContext;  
   2: gridView1.DataBind();

Now, this for when you are just getting your data and binding it to the grid without any type of filters, to use filter let’s construct a class around the items, let’s call it McBurger, actually  internally it infers to the class that we have defined rather building a anonymous type.

   1: public class McBurger 
   2: {  
   3:   public string Code {get;set;}
   4:   public string Name { get; set; }   
   5:   public int Quantity { get; set; }  
   6:   public float Price { get;set;}
   7: }

Accordingly, you can use LINQ statement to do it like

   1: var mcContext= QueryContext.Instance.Load<McBurger>(MGraphCode);   
   2:  
   3: var query = from mcBurger in mcContext
   4:             where mcBurger.Code == "Mc001"
   5:             select mcBurger;
   6:  
   7: // rest of the databinding code remains the same.
   8:  

So, we took the context and queried for specific menu and data grid binding remains the same which brings an output like

image

Actually, Steve and I are pretty excited about this, the possibility of doing things with M is almost endless. Steve has made a more detail post on this and you can find it right at LINQ to M is available.  You can also download the library as well as the sample from Telerik labs and it points to here.

Finally, you can download the example that i have shown from  here.  You will be needing Oslo May CTP to run this sample.

Hope that helps

Shout it

In the last post i said about LinqtExtender implementing necessary property and injecting specific settings for entity objects. The issue i have is that it works fine under full / high trust settings but when running in medium trust it gives the following error:

image

Ouch.. it is only happening while i am using the extender from medium trust environment. As to add a little prologue, actually it creates a proxy around your original entity and if you look closely it is giving the error in .ctor(). Now lets dig in.

   1: ILGenerator ilGenerator = constructorBuilder.GetILGenerator();
   2:  
   3: ConstructorInfo baseConstructor = typeof(object).GetConstructors()[0];
   4:  
   5: ilGenerator.Emit(OpCodes.Ldarg_0);
   6: ilGenerator.Emit(OpCodes.Call, baseConstructor);
   7: ilGenerator.Emit(OpCodes.Ret);

The IL code is pretty simple actually , its the method body of the proxy class constructor that calls default constructor of the base class. Now, this will work fine in full/high trust as here i require the entity class to have a default constructor. But, as i switch the mode to medium trust it will throw me the above exception. The reason why, in medium trust the framework verifies the IL generated and though it may seem from my point of view that its a valid IL as it is expecting default constructor , to framework’s context its invalid as the base object might never have any default constructor (it should throw error in high trust). In that case the call is absolutely suspicious duh…

So the valid block for this scenario would be:

   1: ILGenerator ilGenerator = constructorBuilder.GetILGenerator();
   2:  
   3: ConstructorInfo baseConstructor = null;
   4: ConstructorInfo[] constructorInfos = parent.GetConstructors();
   5:  
   6: bool containsDefaultConstructor = false;
   7:  
   8: foreach (ConstructorInfo info in constructorInfos)
   9: {
  10:     if (info.GetParameters().Length == 0)
  11:     {
  12:         baseConstructor = info;
  13:         containsDefaultConstructor = true;
  14:         break;
  15:     }
  16: }
  17:  
  18: if (!containsDefaultConstructor)
  19:     throw new Exception(Properties.Messages.MustHaveADefaultConstructor);
  20:  
  21: ilGenerator.Emit(OpCodes.Ldarg_0);
  22: ilGenerator.Emit(OpCodes.Call, baseConstructor);
  23: ilGenerator.Emit(OpCodes.Ret);

The code is similar , just it checks for a default constructor , if not throws a valid exception and to medium trust everything looks fine.  I have added a patch for extender with this as well, do check it out.

Finally, while you are doing Reflection.Emit do check this and more like, you should not emit any unmanaged code and even not play around with private stuffs , etc to avoid pitfalls.

Hope that helps

Shout it
Posted Sunday, June 07, 2009 4:14 PM by mehfuzh | with no comments
Filed under: ,

While developing LinqExtender, i have come across various scenarios that people don’t want to extent any query class or even implement any interface. Also, it is almost absurd when they have to add new extender specific attributes to their entity class. It is though not very important for people creating new provider with small codebase but with large codebase it soon becomes a pain to modify each class.

The solution is to make Extender as a container , which is people will write their logic to act on their specific entity or list of entities, also define their settings via fluent interface. To wrap it around , there is a basic ORM that comes with the extender pack and i have a made LibraryContext on top of SqlQueryContext<T>. Inside, the constructor i wrote the following code to define the extender specific settings.

 

   1: Extender
   2:     .Settings
   3:         .For<Base>()
   4:         .Begin
   5:             .Property(x => x.Id).MarkAsUnique
   6:         .End
   7:         .For<Book>()
   8:         .MapToEntity("book")
   9:         .Begin
  10:             .Property(x => x.Id).MapToAttribute("Bk_Id")
  11:             .Property(x => x.ShelveId).MapToAttribute("Shelve_Id")
  12:             .Property(x => x.Title).MapToAttribute("Bk_Title")
  13:             .Property(x => x.BookInfo).MarkToIgnore()
  14:         .End
  15:         .For<Library>()
  16:         .MapToEntity("Bk_Library")
  17:     .InstantiateIn(this);    

Note that there is a base settings that will be applied to all the common properties under my project and is a local class inherited from LinqExtender.Configruation.All. During the instantiation it will be applied to the current container instance.

Now, as i have said extender should be used a container so that there should be no strings attached. In my entity class, i can implement IQueryObject to mark it as a query class, but if not then extender should be smarter enough to implement it internally when the entity is used in LINQ query via extender query class. Actually , under the hood it dynamically creates a proxy via Reflection.Emit that has the settings and ensures IQueryObject. I will in days time come out with a open source project where i have practiced all these reflection stuffs and which i will extensively blog about , so stay tuned.

To make it more clear i have re-implemented the LINQ to Twitter post using the new extender. So few things like implementing IQueryObject and defining unique identifier is no longer required. You can get the new copy at the end of the post. Also, before i forget, there is a tiny catch which is you can’t left the extender auto generate settings, if you are using it in medium-trust as Reflection.Emit does not work in such environment. In that case you will have to implement IQueryObject by hand and add the attributes manually to make it work so i am leaving LinqToTwitter post untouched [See bottom]. I know most of the good hosting providers these days support high trust and soon i think medium trust will become classic with dynamic proxy generation and cross domain request is becoming growing common (Just my two cents, don't want to get in war with these ;)).

In previous release you can access the Fluent implementation of Bucket just by Bucket.Instance, as it seems that i have somewhere statically stored the bucket object and the syntax bit more sexy but considering multiple threads , there is a possibility of data corruption. Therefore Bucket instance is passed to Query<T> overrides as IBucket and new syntax for Bucket.Instance follows

   1: FluentBucket fluentBucket = FluentBucket.As(bucket);
   2: // do your work.

Down to acknowledgement , Microsoft Germany has published two new tutorials around LinqExtender using LinqToFlickr and LinqToTwitter that also led me fix the VB method call issue and thanks Lars and Tim. In German way i would say, “Danke[Dang – ko]”. You can find the recordings in the following URLs

http://www.microsoft.com/germany/msdn/solve/codeclips/library.aspx?id=msdn_de_33389

http://www.microsoft.com/germany/msdn/solve/codeclips/library.aspx?id=msdn_de_33369

Finally, while we are preparing our new Sitefinity release and making some LINQ extensions, bob’s comments were helpful shaping the release as well and nonetheless all community reviews and feedbacks are great. Try the new release here.

Linq To Twitter Source : LinqToTwitter.zip

Enjoy !!!

June 7, 2009 => Correction ,Reflecton.Emit does not work in medium trust for unmanaged IL codes and  possible IL that might destabilize the runtime that it finds by verifying the assembly, will show more on it in upcoming post. Added a patch of extender, this will work in medium trust with auto implementaion and fluent configuration.

Shout it

In a post few month back , i showed how can i simulate a callback using JQuery and ASP.NET with my experimental FlickrXplorer project. More detail on this can be found at the following URL

http://weblogs.asp.net/mehfuzh/archive/2008/10/13/using-jquery-to-do-ajax-form-posts-in-asp-net-mvc.aspx

Now, what i have done here is basically, i did an AJAX call to the controller and rendered the view result in a div.  One thing about this way is that i am able to make the view strongly typed as i first rendered view using standard way with all the strongly type ViewData.Model. It is nice for rendering views with small amount of html in it (Like , tag lists), but slow for big outputs. The best practice for all these is to use the JSONResult. Here, i will show a small example of how i render the comment list in FlickrXplorer using JSON result and JQuery $.get in conjunction to make the AJAX request.

First, let’s see how the controller looks like. Assume that there is a controller named CommentController and we have an action named List

[AcceptVerbs(HttpVerbs.Get)]
public ActionResult List(string photoId, int ? index, int? page)
{
    int skip = index == null ? 0 : index.Value*page.Value;
    int take = page == null ? int.MaxValue : page.Value;

    PhotoCommentViewData comments = new PhotoCommentViewData();

    try
    {
        comments = model.GetComments(photoId, skip, take, false);
        return Json(comments);
    }
    catch (Exception ex)
    {
         /// do some exception tracking
    }
}

As it seems, it gets the list of comment from its underlying model and then pass it through JSON result. Optionally, i limited that the action should only be accepting GET calls as it is a list request.

Now, coming back to JavaScript we first need to do a GET request to this action and syntax for doing it in JQuery style:

$.get(url, { index: index, page: page }, function(result) {

   processComments(url, result, index, page, loaderTarget, contentTarget); [strike though is not covered in the post]

 }, "json");

The first argument is the comment list URL, this is constructed in server side using Url.Action and then passed in the JS that also ensures the routing setup, second is the JSON string for params, third is the callback for the result it fetches and final is the type of response it should contain.

Inside processComments , i basically do some DOM operations to build the necessary html block

$("#layout")
    .append($("<tr/>")
        .css({'vertical-align' : 'top'})
        .append($("<td/>")
        .attr("class", "said")
        .append($("<strong/>")
        .append($("<a/>")
                .attr("href", "/Photo/NsId/" + comment.Author)
                .css({ 'color': '#0063DC', 'text-decoration': 'none'})
                .append(comment.AuthorName))
            .append("&nbsp;says: "))
        .append($("<br/>"))
        .append(comment.Text)));

So, there is a “layout” panel in the comment container where i am to add the dynamic html. jQuery has this nice way of adding html in a chain and elements under it. For example i want to render a html link with some custom CSS and i want to point that to some URL as well.

Using jQuery , i would do

$("<a/>")
 .attr("href", "/Photo/NsId/" + comment.Author)
 .css({ 'color': '#0063DC', 'text-decoration': 'none' })
 .append(comment.AuthorName)

This will render a html tag something like

<a href=”/photo/NsId/x@y” style=”color:#0063DC, text-decoration:none”>Mehfuz </a>

The rule is that you start a element with $(…) in XHTML style then add necessary attributes, styles and text and it will automatically give you a well-formed html,  moreover you can nest it as you like with other elements.

The above block finally produces a look similar to

image

There are few other JS that  is responsible for generating the pager control which is not covered in this post, for this and more you can take a look at the latest bits of FlickrXplorer under www.codeplex.com/flickrXplorer .That’s so far and if you have some cool ideas to share on this,  let me know.

Hope that helps.

Shout it

In this post, i will show how you can generate SQL programmatically from M. Now, so far i have learnt that MGrammer is a contract that converts user’s input into MGraph. Now, Oslo by default comes with MSchema. Through MSchema you can define a type and extend it with MGraph to populate your repository. Here, i will use MSchema to define an entity object , then MGraph and finally run this through a custom SQL generator in C# to get my DDL statement similar to what you can generate by using intellipad that comes with Oslo SDK.

Let’s define a Contacts M

module Contacts {
    type Person {
        Id : Integer32;
        Name: Text;
        Age: Integer32;
    } where identity Id;
    
    People : Person*
    {    
        {Id = 1, Name="Steve",Age=36}, 
        {Id = 2, Name="Kazi",Age=30}
    };
    Employee : Person*
    {    
        {Id = 1, Name="Nike",Age=29} 
    };
}

So, “Person” is a type with ID,Name and Age respectively that is under “Contacts” module with two different MGraph which are “People” and “Employee” that will generate separate create table statements of “Person” type.

Internally , M is  represented somewhat like

image

Parsing the M all starts with Microsoft.M.Parser.SourceParser. In my sample M to SQL project, i used it like

SqlGenerator generator = SqlGenerator.Load(new StringReader(code));
string sql = generator.Generate();

Inside Load…

SourceParser parser = new SourceParser();
syntaxTerm = (CompilationUnit)parser.ParseTerm(reader, "buffer.m");
...
...

/// check if the parse was successful
if (!parser.LastParseSuccessful)
{
    /// do some error processing for invalid schema.
}

Now, once we have a valid grammar, our next step is to get the modules from ISytaxTerm implementation, for each module we have to process the MGraph for the specified type.

foreach (IModuleDeclaration declaration in syntaxTerm.Modules)
{
    builder.AppendSetExtactAbort();
    builder.AppendGo();

    builder.AppendBeginTransaction();
    builder.AppendGo();

    builder.AppendSetANSINulls();
    builder.AppendGo();

    builder.AppendCreateSchema(declaration.Name.Value);
    builder.AppendGo();
    builder.Append(ProcessMembers(declaration.Name.Value, declaration.Members));

    builder.AppendCommitTransaction();
    builder.AppendGo();
}

This shows the basic skeleton of how the output will look like. ProcessMembers is the actual place that generates the entity from type and associates Insert statements. Only, during the MGraph initialization type is realized. Therefore, the table name is equal to the extent name not to the type name.

Inside ProcessMembers …

/// There will be three declaration 
/// -TypeDeclaion
///- ExtentDeclaration
///- ExtnetDeclaration
foreach (IDeclaration declaration in declarations)
{
    if (declaration is TypeDeclaration)
    {
        typeDeclaration = (TypeDeclaration) declaration;
    }
 
    if (declaration is ExtentDeclaration)
    {
       /// use the type declaration from previous step.
        builder.Append(ProcessExtent(name, typeDeclaration, (ExtentDeclaration) declaration));
    }
}

TypeDeclaration is narrowed down to ParameteriedExpression , which has different operations for the declaring type, which is tracked by  DeclartionReference.Name (“$Operator$Where”, “$Operator$Identity” , etc). Therefore, to process constraint and data types separately, we need to switch them for operation type.  Now, the question is how the MGraph is referred from the type specified. The JSON like string  is basically translated to GraphExpression. Like for the “Person” type , we have three properties. GraphExpression.Successors.Count will be equal to numeric value 3 and each of those which are GraphExpression themselves will have only one successor which is a M.Literal. This will actually contain the property name, type and value for parent type ref.

GraphExpression graphExpression = (GraphExpression) extentDeclaration.InitialValue;

if (extentDeclaration.InitialValue != null)
{
foreach (GraphExpression successor in graphExpression.Successors)
{
    int index = 0;

    foreach (var expression in successor.Successors)
    {
        if (expression is GraphExpression)
        {
            GraphExpression node = (GraphExpression) expression;

            Literal literal = (Literal) (node).Successors[0];
           /// process fragment
        }

        index++;
    }
   /// process the final statement
}

That’s all to get started. All the code has been taken from a MSqlProvider that i created while learning M. The technology is itself in bleeding edge so things will change and i will share my updated knowledge forward. You can further enhance MSQLProvider to run the result in configured database along with the mx.exe that comes with Oslo SDK.

You can download the source here to play around and see it live.

Enjoy!!

kick it on DotNetKicks.com

More Posts Next page »