Ever since NuGet came online I’ve been wanting a way to find out about new packages, and updates to packages.

Since OData extends the ATOM feed and you can hook an OData feed up to any RSS reader I set out to find a way to get at those recent updates to the NuGet feed and find out when new packages were published.

If you’re not completely familiar with OData, later in this post I explain how I arrived at the URL below. However, if you don’t care how I arrived at the solution, below is the final RSS link I’m currently using in my RSS reader (Google Reader) to monitor updates to the NuGet feed.

http://packages.nuget.org/v1/FeedService.svc/Packages()?$filter=Id%20ne%20'SymbolSource.TestPackage'&$orderby=Published%20desc

How did I discover or build that URL?

I could have memorized the OData URI spec and constructed the above link by hand but I’m far more familiar with C# and LINQ and instead used LINQPad.

Open up LINQPad and add a WCF Data Services (OData) connection to the following URL

http://packages.nuget.org/v1/FeedService.svc

Now You can query the OData feed with some LINQ.

from p in Packages
where p.Id != "SymbolSource.TestPackage"
orderby p.Published descending
select p

When you execute this LINQ query in LINQPad, you can click on the “SQL” in the results pane to view the URL that was generated to execute the operation.

Now my original linq expression didn’t have the where p.Id != "SymbolSource.TestPackage" as I didn’t know this package would become a regular pain to view in the RSS Reader.

One great thing about OData is the ability to re-craft the URL for this feed to ignore items that either show up so much that I want to exclude them (like the “SymbolSource.TestPackage”) or a certain class of items that I just don’t want to be alerted on (maybe filtering by the NuGet Tag property).

Some observations of the feed.

I’ve been monitoring this feed for almost a month now and have learned about some very interesting projects, check the next section of this post with a list of some of the more interesting ones (to me) that I’ve found.

So far the feed has become just a regular part of my daily blog reading. It’s the quickest one to do as I’m typically skimming the titles of the RSS items and only slowing down to dig into projects I’ve never heard and sound interesting.

Google Reader trends that this feed generates about 54 items a day. Which may seem like a lot, but it’s really easy to click the “mark all as read” button and go on with the day.

Interesting projects I’ve discovered.

I’ve been watching this RSS feed for almost 2 weeks now, and have discovered some new projects (at least new to me) and learned about updates to projects I already knew about.

Below is a small list of ones I thought were interesting – there’s way more being done out there.

New to me

• OpenCover
• NodeJs (Package) Installer
• SignalR
• FastActivator (this one feels like it could be a single .cs file instead of a full assembly – but then I guess you couldn’t leverage it in say a VB or F# project)
• EasyHttp
• SheepAspect

NOT new to me (but released while I was watching)

• SassAndCoffee
• FubuMVC
• Bottles
• StatLight (Ya I know it’s my project – but good verification that when I released the project – it showed up in my RSS reader.)

Could NuGet be a new metric for what’s popular or up and coming?

That heading is a little bolder than what I actually think, mostly because there are far too many variables to make that statement hold a strong footing. Regardless, I have noticed some interesting “trends” (if you can define a trend by my watching the feed for about a month) in what is being released on NuGet and wonder if watching this over time will be a nice window in to the types of projects people are really working on.

I’ve seen quite a few projects related to messaging or Event Sourcing. And a number of different JS and CSS minification/build tooling projects.

In a previous post I elaborated on the problem of magic strings in OData service queries, and gave a quick (but lacking in depth) statically typed helper solution.

A commenter mynkow left a note stating that my solution would not work with nested objects. I initially replied asking if he could give an example (as I hadn’t run into that scenario yet being a noob to OData). He didn’t get back to me, but it wasn’t long before I ran into the problem he was talking about.

If we go back to LinqPad and look again at the Netflix OData api. Let’s say we want to pull down the People, their related TitlesDirected and the TitlesDirected ScreenFormats. (No real world scenario there – just made it up because they’re related properties). The OData query (with magic strings) would look like:

(from x in People.Expand("TitlesDirected/ScreenFormats")
select x).Take(5)

If you tried to take the above and translate it to my “no magic string” fix from the previous post you would get something like.

(from x in People.Expand(p => p.TitlesDirected /* Now what? dead end. /ScreenFormats*/ )
select x).Take(5)

Now that the problem in my solution was apparent, and using his example as a quick guide (It wasn’t quite what I was looking for, but had the general theme). The solution became more than a few lines of code and I wanted to wrap some tests around the whole thing just to verify it was all working correctly…

ODataMuscle was born:

http://github.com/Staxmanade/ODataMuscle

Sorry for the name. Just think of “Strong Typing” your OData queries and giving them a little Muscle. I threw this little project up on github since this blog is not the best place to version code and if anyone felt inclined to extend it they could easily fork it and do so.

I hacked the initial version together, and once a co-worker of mine was done with it I think he cleaned it up nicely.

This new version now supports expanding not only child properties, but grandchild properties and grandchild properties of collections. (That doesn’t seem to translate well…)

EX: our little Netflix example from above would now look like

(from x in People.Expand(p => p.TitlesDirected.Expand(p2 => p2.ScreenFormats))
select x).Take(5)

Which would translate into the following query

http://odata.netflix.com/catalog/People()?$top=5&$expand=TitlesDirected/ScreenFormats

Thanks to mynkow for the initial feedback and I hope this helps someone else…

I was experimenting recently with the .Net implementation of OData and ran across one of my pet peeves. “Magic Strings”. Apparently, the .Net community’s definition of magic strings is close but seems slightly different from Wikipedia. Therefore the magic strings I’m talking about here are what you’ll find on such posts as “Functional .Net – Lose the Magic Strings.”

I don’t want to get into the magic string debate here, just that I want to snapshot this little helper (for when I need to remember to write it again and don’t want to “figure it out”). This is also not intended to be a complete overview of OData, but I will provide some getter starter links and tips (if you haven’t touched it).

Enough background show me the code: (scroll to the bottom if you don’t care about the post)

Let’s pretend we want to request a “Title” from the NetFlix OData api.

You can do this by going to the web browser and typing the following URL

http://odata.netflix.com/catalog/Titles()?$top=1

Sweet. XML, yippie. Um, no thanks. Let’s try that again. Go download LinqPad (read up on using LinqPad for querying an OData store)

Once you’ve connected LinqPad to the NetFlix OData service (http://odata.netflix.com/catalog). Now we’re ready to play around. Our URL “query” above translates in to a C# LINQ statement that looks like the below in LinqPad.

(from title in Titles
select title).Take(1).Dump()

The .Dump() is a LinqPad extension method that displays the object in the results window.

If you execute this in LinqPad you will see some data about the first Title form the Netflix OData service. In the results window scroll all the way to the right. Notice all the properties that are supposed to be a Collection<T> but have no data? To retrieve these through OData you have to extend your LINQ query with the Expand(“{propertyName}”) method.

Let’s say we want to include AudioFormats collection when we ask for the first Title.

(from title in Titles.Expand("AudioFormats")
select title).Take(1).Dump()

Notice how we have to explicitly tell the OData service to include this property when we retrieve it form the service. Not only do we explicitly tell the property name, but it’s a magic string (gag, hack, baaa) none the less. If you click on “SQL” in LinqPad result window it will show the URL used for OData queries. Our URL shows the expanded property.

http://odata.netflix.com/catalog/Titles()?$top=1&$expand=AudioFormats

Now let’s pretend (just for the sake of pretending) that your front end application’s entire data access strategy was going to sit on top of OData. Not saying this is a good thing (or a bad thing). Just sayin…

If you have a fairly complex data model and each screen in your application requests slightly different data in a slightly different way, but in the end it all essentially comes down to a set of entities and their relationships. What would you do if you had to “.Expand” all those magic stringed property names. Now, I know we’re all great at search and replace (of the magic strings). However every little step along the way where I can avoid a refactor that will break every other screen in the app, well, I think I just might take that.

Now, if you change your LinqPad query from a “C# Expression” to a “C# Program”. Copy the helper class at the bottom of this post in to the bottom of the LinqPad code window. You can now write your linq statement as follows

(from title in Titles.Expand(x=> x.AudioFormats)
select title).Take(1).Dump();

Notice the switch from magic strings to an intellisense helping, refactoring safe lambda? This trick is not new. You’ll see it in many .Net open source projects such as mocking frameworks, asp.net MVC projects etc…

Just wanted to write this little goodie down for the next time I need it. Hope this helps someone else as well.

public static class ServiceQueryExtension
{
    public static DataServiceQuery<T> Expand<T, TProperty>(
        this DataServiceQuery<T> entities, 
        Expression<Func<T, TProperty>> propertyExpressions)
    {
        string propertyName = propertyExpressions.GetMemberName();
        return entities.Expand(propertyName);
    }

    public static string GetMemberName<T, TProperty>(this Expression<Func<T, TProperty>> propertyExpression)
    {
        return ((MemberExpression)(propertyExpression.Body)).Member.Name;
    }
}