The official Sitecore NuGet feed is here!

Wild times in the Sitecore world, as the release of v8.2 is has brought a load of new features. One I'm particularly pleased about is that there is now an official NuGet feed for your Sitecore references. I've been asking pretty much every Sitecore employee I've spoken to about doing this for years now, and finally it's here.

So now I've read the release notes and finished a quick chair dance of joy, it's time to dive in and see what it's all about...

So what are Sitecore providing? url copied!

Well there's a new URL for their official NuGet feed: `https://sitecore.myget.org/F/sc-packages/api/v3/index.json`

NB: As pointed out by Matthew Dresser in the comments below, this is the feed URL for 2015+ versions of Visual Studio and NuGet v3. If you're using an older 2012+ version you need this url instead for v2 of NuGet: `https://sitecore.myget.org/F/sc-packages/`

You can add this to the Visual Studio feeds dialog in the usual way:

And it can also be added into the NuGet.config file for solutions you plan to use hosted builds for. (See my previous post about hosted builds for details of modifying that file)

When you look at the packages in that feed, there are quite a few. Sitecore have built a tree-like structure that goes from top level "meta packages" down to individual DLL packages. This gives you a lot of flexibility about exactly what you want to reference, but it can make the initial list a bit intimidating. Don't worry though – it's all pretty logical.

The top level package is called Sitecore. It has versions for 7.2.x and 8.x.x – there are no 7.5.x packages as Sitecore have previously said that 7.5 isn't getting long term support. This package doesn't contain any DLLs itself (hence the "metapackage" description) – it just has dependencies on a series of other feature packages. The exact list will vary depending on the features available in a particular release, but for the latest version of v8.1 I'm currently using it is:

Each of those feature packages then contains further dependencies and references. For example, the Sitecore.Analytics package adds the Sitecore.Analytics.dll binary as a reference and then depends on:

Note that not all of these are packages created by Sitecore: The Newtonsoft.Json package is included here. According to their documentation, Sitecore have included standard Nuget.org references to third party packages where they are available.

However some of the 3rd party DLLs are not available in packages - so you may need to make alternative arrangements for referencing them. If you look closely at the descriptions of each package, they tell you what they don't include – so you can get hints about what you might have to handle yourself from within the NuGet feed dialog. For example, the package for Sitecore.Kernel says:

So you can copy these out of your /bin folder and reference them by making your own private package, or whatever other way suits your solution best.

Now, if you search through the contents of Sitecore's NuGet feed, you'll notice that there are a collection of packages with names that have .NoReferences at the end. For example, there is a Sitecore.Analytics.NoReferences package as well as the Sitecore.Analytics package mentioned above. What's that all about?

Simple – the .NoReferences packages include the binary files but don't have dependencies on other packages. So if you want to pick out individual DLLs without having to import all of the other assemblies that file depends on, choose these packages. It's a bit more effort to manually add each of these that you need – but it means your project only refers to the specific files you want. My gut feeling is that these are probably the packages you want most of the time – since most Sitecore development is "I am writing some code which depends on Sitecore" – you only need to include the assemblies that your code actually depends on at compilation time in your solution. All the other assemblies which are required to actually execute code will be available when you deploy – since they're in your website's /bin folder.

Another point made in the documentation, is that these packages don't adjust the "copy local" flag when they're added to your solution. You may wish to change this property on your referenced DLLs manually where it's appropriate.

Adjusting your build to use the new feed url copied!

So once you've added the right settings to Visual Studio / `NuGet.config` to be able to resolve theses packages, what do you need to do to a solution to make use of the feed? Simple really: just remove your old references and add the new ones from Sitecore's feed.

I've been using a sort-of-representative test project (see below) for my hosted build and unit test research recently. Modifying that to use the new feed involved the following changes:

• The code project This one's simple enough. You just have to add the references for whatever your code depends on. For the code I was writing, that was just Sitecore.Kernel.NoRefrences. Though you may find it's easier to use packages that include the references – it all depends on the complexity of your project I think.
• The FakeDB Tests project The reference requirements for FakeDB are described in the installation instructions. So you can add Lucene.Net from the ordinary NuGet feed, and then the .NoReference packages for the remaining four assemblies. You may also need to add any other dependencies your code has, as per the code project bullet above.
• The TDS project If you're going to use the package building features of TDS, you need to make sure that some DLLs are available to it for generating the package. It requires Sitecore.Kernel, Sitecore.Logging, Sitecore.Zip and Sitecore.Update to work. You can't add NuGet packages directly to a TDS project, but it's clever enough to look in your packages folder and find them if you've installed them elsewhere. Since I was already using Kernel and Logging for my FakeDB project, I chose to just add the Zip and Update .NoReference packages to that project. Having thought about this a bit more, I realise you can add packages directly. You don't seem to be able to do it via the NuGet UI, but you can have a packages.config file in your project:
  
  So you can add these extra packages to that file, and TDS will be able to find them:

  <?xml version="1.0" encoding="utf-8"?>
  <packages>
    <package id="HedgehogDevelopment.TDS" version="5.5.0.15" />
    <package id="Sitecore.Update.NoReferences" version="8.1.160519" targetFramework="net452" developmentDependency="true" />
    <package id="Sitecore.Zip.NoReferences" version="8.1.160519" targetFramework="net452" developmentDependency="true" />
  </packages>
  
  							

  And it is clever enough to find the other two packages in your \packages folder even though this project doesn't directly reference them. (Though it can, of course)

One thing to note here, as you're adding lots of different packages. Slightly annoyingly, the NuGet reference dialog always defaults to the latest package version when you select a new package. So if you're not trying to install packages for the v8.2 release, you need to remember to check you've picked the right version every time.

One minor oddity I noticed – the Sitecore.Nexus reference comes in two different packages. There's one for the v7.x and v8.1 versions and one for the v8.2 version. Take care to pick the right package if you need to add a reference for that.

Once you've correctly updated your references, you should be able to run your build and tests locally. And then your hosted builds should run fine too:

Success!

Working through all of this, I noticed an odd side-effect of using multiple package sources in Visual Studio. If you add a private feed (which requires authentication) to your solution, then you'll get prompted for credentials whenever Visual Studio needs to connect and doesn't have a valid credential to hand. Oddly, if your authentication fails or is cancelled for any private feed, you cannot restore packages from any feed (authenticated or not) until you resolve the credential issue. And sometimes that involves closing and re-opening Visual Studio.

So get your credentials right...

NB: In case anyone wants to see what I changed in my test solution for hosted builds, it is available at on Github. You'll need to provide your own source for the TDS and FakeDB License file NuGet packages if you want to build it, however. (As I have them in a private feed) See my previous two posts on feeds for info about doing that. But I figured it might be of interest to some people none the less...

↑ Back to top