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...
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: `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
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
package adds the
binary as a reference and then depends on:
Note that not all of these are packages created by Sitecore: The
package is included here.
According to their documentation, Sitecore have included standard
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
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
at the end. For example, there is a
package as well as the
package mentioned above. What's that all about?
Simple – the
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.
So once you've added the right settings to Visual Studio /
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:
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.
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.
.NoReferencepackages to that project.
packages.configfile in your project:
<?xml version="1.0" encoding="utf-8"?> <packages> <package id="HedgehogDevelopment.TDS" version="126.96.36.199" /> <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
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...