In July 2011, Henrik Feldt created a NuGet package for re-linq 1.13.111. Only one year later, we took notice of that, when Chris Eldredge and Gordon Watts gently asked us to update the outdated package.
Starting with re-linq 1.13.161, we’ve therefore decided to regularly publish NuGet packages in the course of our weekly build. The release policy is currently the same as for our CodePlex releases: whenever we have changes such as bugfixes or new features, we’ll release a new build of re-linq.
Note that the versioning of re-linq is still bound to that of re-motion as, for now, the two projects are built together. This means that, at the moment, re-linq does not follow semantic versioning – new releases may contain fixes, new features, or breaking changes, no matter how the version number changed. Also, strictly speaking, all 1.13 builds are internal builds without any support guarantees. On the other hand, these are also the builds we’re using at rubicon, and we have confidence in their quality, so there isn’t much reason not to use them.
Also note that the Remotion.Linq NuGet package only contains the re-linq front-end. If there is demand for a SQL Backend package, please tell us so.
The packages we release to NuGet are symbol packages, which means that you can debug them and step into the code if you want to. You need to configure Visual Studio to disable Just My Code, enable source server support, and add SymbolSource.org as a symbol file location. And then…
There is one caveat with debugging: The NuGet package contains the Release build of re-linq, so debugging might sometimes be bumpy, since the source code does not reflect the optimizations made by the C# compiler. But even so, when I tried it, it worked quite nicely.