runtime compilation of Linq code

runtime compilation of Linq code

• Bhanu_Prakash

  Of course it's reasonable to expect the code providers to be updated in the release version (ASP.NET, for example, makes use of such providers). But until then, you might just have to wrap csc, depending on how much (or little) work you're wanting to take on.

  Extending espresso may be simpler, though...

  
  
  

• Ekta

  I ended up trying both ways, as playing with compiler is I think the best thing in programming.

  After all, isn't giving meaning to abstraction the crux of programming

  So, bottom line is :

  1. If I use the natice csc Linq compiler (by an ugly process wrapping), it works but I loose the ability to feed my own namespace

     For instance, my business object that I want to query is a "Bench" that has products, portfolios, currencies and other properties. So I'd like to write queries like

     Products.Where(p => p.ProductName.Length == 4);

     Which translate before compiling to

     static public Expression<Func<BenchViewer.BenchDB, IEnumerable>> f0 = b=> b.Products.Where(p => p.ProductName.Length == 4);

     Now I'd like to abstract that query and make this compatible with dynamic metadata. One usecase would be for instance composed queries where one query to be written on top of another. So I'd prefer my query to translate into that code before compiling :

     static public Expression<Func<BenchViewer.IDomainnameProvider, IEnumerable>> f0 = b=> b.Products.Where(p => p.ProductName.Length == 4);

     And that, encoutnering the unkonwn symbol "Products", the compiler would call me back for me to resolve this type in my context. This type does not exists in the context of IDomainnameProvider, which is a general interface, but exists in the context of my "Bench" instance which exposes the name "Products" as one of its property.

     Helas, I dont know of a way to have external symbol resolution for the compiler.

  2. Second option, I extend Espresso. this is a funny job, and adding few feature is is simple. Adding lambda expression resolving to method invoke to "object" is simple too, but leave a bad sensation of unfinished work. So problem arises with type inference. I dont know yet how to do this. May be it is not even possible with such a parser...

  Bottom line is if you know clean ways to do this, I'm interested.

  Also, as I want to write a simple "querier", I realize there is still lots of work in the programming area to deal with. The consequence of this is that it is important that MSFT leaves it open for third parties to provide with technical answers. In terms of business, MSFT will always have the means to streamline the new solutions, so it can only profit of such a stance.

  Nicolas Rolland

  
  

• turnkey

  Why would you need it

  You might create source code and invoke Linq compiler to generate an assembly, inmemory perhaps.

  
  
  

• Gregory Dye

  Hi,

  I'd like users of my app to write queries themselves.

  So I have some parser and translation work to do.

  For the parsing, one way which I did is to plug my app to and extend the Espresso sample to support queries to be built against typed namespace of mine.

  Another way would be to reuse the compiler capacities of Linq, because I jjust felt bad redoing all this work done superbly by the superb Linq Team ;)

  Your suggestion is to make a raw call to the Linq "csc.exe". I hoped there was a more programmatic way to do this. If you know one, please tell, it might interest other poeple.

  Nicolas

  
  
• runtime compilation of Linq code