What's the secret to getting started from Nuget?

[Pat]

My going in assumption is that the easiest way to quickly get up and running with a new package is to install from NuGet, refer to some samples or reference implementation documentation.

In the case of dotnetopenauth, I install the package from the nuget console and get sixteen dlls, none of which correspond to the assemblies in the reference documentation which all seem to expect a single dll. 

I gave up and downloaded the zip and am making progress now.  In the zip file's samples, there is a note stating "DotNetOpenAuth.dll the only runtime dependency for web sites to use this library."  So...what's up with the sixteen assemblies from nuget, none of which are DotNetOpenAuth.dll?

It seems contrary to the goals of deploying through a package manager like nuget to install assemblies that are nowhere referenced by the sample code or documentation.

[Andrew Arnott]

Hi Pat,

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 DotNetOpenAuth.Ultimate package 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, 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.

--
Andrew Arnott
"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

--
You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.
To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/RAnMKuFkeecJ.
To post to this group, send email to dotnet...@googlegroups.com.
To unsubscribe from this group, send email to dotnetopenid...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/dotnetopenid?hl=en.