Updated with new information about NuGet feeds for 9.1
Previously, the 9.1 packages were in a separate feed, as of March 4th 2019, these have now been moved back into the main feed. The NoReferences packages are still removed.
To avoid link rot, here are the feed urls for the official feeds:
For all versions:
NuGet V3 feed URL (Visual Studio 2015+)
PackageReference is a new way to allow NuGet to manage your projects references. Before this, adding a NuGet package would update both the packages.config file and the .csproj file for your solution. The packages.config contains the package name and version, and the .csproj file contains a reference to the downloaded package on disk.
Certain functionality in Sitecore 9.2 requires an explicit dependency on System.Buffers 4.5.0. However some dependencies for Sitecore 9.2 have a transitive (indirect) dependency on System.Buffers 4.4.0. Thus, Sitecore 9.2 includes this bindingRedirect:
<assemblyIdentity name="System.Buffers" publicKeyToken="...
The package without NoReferences suffix brings dependent Nugets containing additional DLLs. These DLLs are defined as dependencies in Nuget definition. If you check the dependencies list you will find Sitecore DLLs and third party DLLs like Newtonsoft.Json or HtmlAgilityPack in it.
The package with NoReferences suffix does not bring any dependencies. ...
Sitecore did have 9.1 in its own feed to more closely match the way Sitecore does builds internally. https://sitecore.myget.org/gallery/sc-platform-9-1
But Sitecore heard feedback from the community and the decision was made to move it back into a feed where multiple versions will be together. This will classify all the Sitecore dlls together under the same ...
In 2019 the answer is little bit different.
Sitecore will not release new NoReference Nuget packages. But you can get similar behavior by usage of -IgnoreDependencies setting:
Or by command line:
Install-Package -Id <package name> -IgnoreDependencies -ProjectName <project name>
If you want more details, there is good article that describes ...
At the very least, you'll want the Sitecore.Kernel assembly which contains the core API and most of the utilty classes you will use when working with Sitecore:
For working with MVC, grab the MVC package:
If you are going to be using ContentSearch and will work with Lucene indexes, you can get:
If you are making Web.config changes (which would be required for adding an HTTP handler), I would say that this is not something that should be just "installed" on your servers. You want to maintain the accuracy of your Web.config in your source, right? I'd also be worried about deploying Web.config changes in such an ad-hoc way (rather than following a ...
The no-references packages allow you to add only the packages you need to your project.
Consider a package that preferences Sitecore.Kernel. The package may need Sitecore.Kernel, but not any of the packages that Sitecore.Kernel references (such as Newtonsoft). The no-references package allows you to reference only Sitecore.Kernel.
When using some smaller,...
On the TDS Project, you need to
Right click on the project and click on Properties.
In the General Tab, you will see Assemblies.
Select Include from the dropdown.
Add the name of the assembly you want to add in the update package.
Save the changes.
From @Jay S, the DLL also needs to be referenced in some way by the web projects being built in order ...
The official Sitcore Nuget feed is hosted on myget.org as @Adam correctly points out the details are in that document.
You can also read up more details about setting this up for your project in this blog post about the nuget feed but if you have an existing project that you want to migrate all references on, esp on a project which follows Helix guidelines ...
After trying almost everything and searching half the internet, I found the solution here: https://docs.microsoft.com/en-us/nuget/consume-packages/managing-the-global-packages-and-cache-folders
And especially the magic button in Visual Studio on this screen:
Once I cleared my Nuget caches -and removed all my package files once again- the restored packages ...
This is a known/discussed nuget issue -- what seems like information is output by nuget as a build error. As of 9.1 the published nuget packages are those used internally by Sitecore ("release what you test"), so in dependency version ranges they may reference versions that are not released publicly.
You can suppress this error in your project's build ...
This is a known issue with restoring NuGet packages:
Currently, there seem to be at least two ways to "fix" it (kind of) that work with varying success rates:
Restore packages manually using Visual Studio's context menu for your projects;
Use NuGet 3.5 RC1 and restore the packages using the command line: nuget ...
The package was renamed on nuget, what you want is the mongocsharpdriver package. You can get 18.104.22.168 by using:
Install-Package mongocsharpdriver -Version 1.10.0
That package contains boths MongoDB.Driver.dll and MongoDB.Bson.dll.
Here is the nuget page for the older project:
Which has now been ...
Ignoring my NuGet approach above; the only obvious option you have available is a lesser-known feature in Sitecore packages called "poststep". Essentially you can instruct Sitecore to execute some code, after your package has installed.
Sean Holmesby describes it here: Sitecore Upgrade Post Step Scripts
While the blog post mentions this in regards to ....
Change your build target from 4.5 to 4.5.2 in your project properties.
The MS dependencies will not be compatible with 4.5 since that is now unsupported. So it can't find a dependency that matches your project target and fails.
It happened to me once and I fixed it by clearing nuget cache as Gatogordo
But for some reason it doesn't work anymore even when I clear cache manually.
I got tired of it and wrote a script. It targets libs I had issue with Sitecore*9.0.180604
run it from packages folder and it will rename 452 to 462. It is safe to do as I noticed those libraries target ...
So the answer was to remove this NuGet packaged manually by editing the project.json file. Apparently this package is not needed by the solution so removing it was safe. There must be an issue with the package because even when I readded it from NuGet it still errored. Something Sitecore will need to fix.
There are few different types of NuGet packages available with Sitecore public NuGet. One type is, with all the references, which is the one you have mention. Other type is Individual dll Nuget packages.
If you want individual dlls, then you can use .NoReference dll NuGet Packages from Sitecore public Nuget source.
There is a way to do this. Has nothing to do with Sitecore though; but NuGet.
The snippet you posted; you can place this into a file called web.config.transform, to have it added to the existing web.config.
While I share some of the concerns raised above; this is definitely something you would want DevOps to know about (use the readme.txt file, for ...
Finding Matching DLLs
There is no documentation, and unfortunately it's sometimes an educated guess which DLL contains the code you need to reference.
Since you know the Class/Namespace you are looking for, you can use a search tool to search through all the DLLs on the filesystem to find a match. I have found this to be the quickest way to narrow down to ...
To ensure you have complete control of the references you use in your solution I would argue you should always use the .NoReferences packages.
There is a good overview of the package source feed and some thoughts on when to use the .NoReferences suffix in this blog post https://jermdavis.wordpress.com/2016/09/05/the-official-sitecore-nuget-feed-is-here/
Not all modules are available (yet) in the Sitecore Nuget feed. SXA for example is not there yet, and it seems like the Publishing service is also (still) missing.
For the moment, you'll need to refer your solution to the dll locally. You can always contact Sitecore (through support / uservoice / ... ) requesting to get the Publishing service module in ...
The problem with Ignore Dependencies, as you point out, is that it is a global setting. While it can be fine to pick and choose from Sitecore assemblies, which ones you want in your project - it is not so easy and obvious when it comes to other third party libraries. Like for example MVC, as you state in your example.
If you don't want to move to ...
The method I've found to be the most useful for testing the same code against multiple versions of Sitecore, is to setup with the use of Sitecore Instance Manager a starting website instance, such as 8.2.5. Once that is setup, I will start creating my Visual Studio Solution. I will then use Gulp to create a Libraries folder in the same folder as my ...
I'd like to add to Hishaam's answer and note that this can be done in the TDSGlobbal.config file. The following config is taken from Hedgehog's fork of Habitat. Using the ExcludedAssemblies nodes, you can specify to all TDS projects in your solution to not include any Sitecore, Lucene, etc dlls. Configured correctly, it would include only your ...