Excellent questions. It looks like some of our documentation is out of
date. It's also a less simple story than it used to be, so the docs are
actually correct in same cases, incorrect in others. I'll explain.
Several large customers have asked for the many features in DotNetOpenAuth
to be broken up into individual assemblies so that they can pick and choose
exactly which code to host or redistribute. We've mostly resisted this
request because most folks seem to like having just one DLL. But when
Microsoft proposed adding DotNetOpenAuth to Visual Studio 2012 itself but
under condition that we break up the assembly into smaller bits so they
could include only some of them, that was a compelling enough reason that
we finally went for it.
There is still the old-style monolithic DLL option that is still supported.
As you've discovered, one way to get it is to download the .zip file. But
you can also get it via NuGet by installing the
instead of the "DotNetOpenAuth" one.
The recommended NuGet package to use is "DotNetOpenAuth", which itself is
empty but depends on the other DotNetOpenAuth packages so that you get the
same functionality that you're used to -- across many different DLLs. If
you only use a slice of DNOA's features, you can install one of the more
specific packages <https://nuget.org/packages?q=dotnetopenauth>, which
themselves may depend on a few others, but you'll get fewer DLLs this way.
The reason the broken up package model is recommended over the unified one
is that there are now several 3rd party NuGet packages available that apply
front-ends to DotNetOpenAuth that add functionality. These will
(hopefully) always depend on the smaller packages, so by consuming the
smaller packages yourself, if you ever add a NuGet package that depends on
DotNetOpenAuth, you won't find yourself with *both* styles in one project,
which won't work out so well for you.
I hope this helps.
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre