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 what are Sitecore providing?
Well there’s a new URL for their official NuGet feed:
[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:
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
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
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
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.Netfrom the ordinary NuGet feed, and then the
.NoReferencepackages 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
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 UpdateHaving 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
.NoReferencepackages to that project.
packages.configfile 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="188.8.131.52" /> <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
\packagesfolder 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:
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…