Expert to Expert: Inside LINQ-to-SharePoint

Play Expert to Expert: Inside LINQ-to-SharePoint
Sign in to queue


You first met Bart De Smet in an episode of Expert to Expert with the great Erik Meijer leading the conversational charge. LINQ-to-Anything was a very popular E2E episode and the 100th installment of Going Deep. If anybody in the world is an expert in LINQ-to it's certainly Bart. Not surprisingly, Bart created an implementation of LINQ-to-SharePoint before he started at Microsoft. The SharePoint programmability team was impressed and decided to take a stab at a more robust solution, based loosely on Bart's great work.

Well, here we are today with a new installment of E2E and Bart leading the conversation with two of the key SharePoint team members behind LINQ-to-SharePoint: Program Manager Maxim Lukiyanov and Software Developer Ivan Han.

Here, we learn all about the thinking behind the thinking (rationale, design decisions, solution paths, etc) and where this approach will lead the SharePoint programming experience for pro and non-pro developers alike. We also learn that Bart has joined Erik Meijer's team of superdevelopers! I think Erik just may have the most talented team of creative thinkers and techinal over-achievers in the company! Go team, go!

Tune in. Enjoy.

Here's the two links you need to click on to get started. Please provide feedback!!

SDK with LINQ-toS-SharePoint API

SharePoint Server 2010 Beta



Download this episode

The Discussion

  • User profile image

    Awesome to see Bart step up to be Erik's "expert co-processor" Smiley I've really enjoyed Bart's recent blog writing on MinLINQ (wonderful diagrams too, check it out if you haven't already).

  • User profile image

    Good discussion. Interesting perspective on how customer-extensible application meta-data affect all the layers above.

    And it's rather obvious that "like.. you know" Bart now works for Eric.


    Just out of curiosity, what is so special about SharePoint security that computation has to happen in the business layer as opposed to a stored procedure or even a correlated subquery in a SQL statement?

Add Your 2 Cents