When the Entity Framework was first introduced it came with (basically) two flavors of querying. LINQ to Entities and Entity SQL (ESQL). I’m not going to describe the history here. But as LINQ (any LINQ) gained popularity it was obvious, that LINQ to Entities is a future (though it had initially small deficit compared to Entity SQL). I even on my courses recommend using LINQ to Entities whenever possible and I’m also showing some dynamic querying where normally people start concatenating ESQL strings.
Recently Entity Framework added support for spatial data (and enums, …). All examples I’ve ever seen around spatial data and Entity Framework were using LINQ (obviously). Only few weeks ago I realized how the querying should work with Entity SQL. As it turned out spatial data are not first class citizen in Entity SQL world. There’s no literal for i.e. point. But canonical functions are here to save you. There’s a bunch of these spatial data related. What we’re looking for though is GeometryFromText/
GeographyFromText. With these you can construct Geometry/Geography datatype from well-known text (WKT) and use it in query.
I’ve never used Entity SQL query in any real-world application I created. I’m too afraid of typos etc. But I did a lot of magic with expression trees. 
Wondering what percentage of people using Entity Framework is using Entity SQL and whether there are some scenarios that are crazy hard in LINQ…
) and it came with some new features and improvements (hence version 3.0.0). And as it goes, nothing is perfect and few items slipped through testing phase. So that’s th reason why today, I’m happy to announce version 3.0.1 to be released.