This project is read-only.

Any interest in moving LIB to NuGet?

Topics: Core
Feb 25, 2015 at 7:46 PM
Checking binaries into GIT isn't a great practice. And the dual systems of having both in-place and NuGet dependencies can quickly drop you into DLL resolution hell.

My team is thinking about taking a fresh branch off of Orchard master or 1.X, moving everything to a NuGet, testing everything, and then generating a Pull request.

How does everyone feel about that? Any requirements from the dictators?

Feb 26, 2015 at 1:45 PM
See: Also I started a feature/nuget branch with similar intentions (although what is done there is the "opposite": to make Orchard available as a NuGet package to be added to a standard ASP.NET web project).

I have mixed feelings. While I agree that storing binaries in source control is generally bad, I see no practical drawbacks in case of 3rd party libraries. Not using NuGet is however a super-simple solution, i.e. you clone the source and run. The negative implications written here still stand and will probably remain forever because these are true for the nature of online package managers: It's a question where we want to compromise.

Having everything come from NuGet sounds great at first for me, but that would be one more external resource (as in the NuGet feed) and technology (as in NuGet package management) that we depend on and what will affect us when it changes.

One particular disadvantage: not all dependencies of ours are used in the released version. At least NHibernate is a patched build, maybe there are others as well. Now this is again something theoretically wrong to do, but the alternative would be to wait a year for a suitable release...

So all in all IMO moving to NuGet I'd consider something great and cool to have, however not something that would necessarily simplify or generally make better anything and I can feel a lot of workarounds and hacks coming to fight around edge-cases that we currently have seamlessly integrated. My subjective opinion of course.
Feb 28, 2015 at 9:57 PM
Edited Feb 28, 2015 at 9:58 PM
I disagree with your assessment of it not simplifying things, as we recently have felt pain with extending this project reliably using up-to-date libraries. Not using Nuget in a comprehensive way makes upgrading dependencies holistically very difficult, because you can't rely on Nuget to do its intended functionality (solution wide package dependency resolution and updates). This gets even more difficult with packages that need newer lower level updates, like Newtonsoft.Json, or even worse System.Web.Http.Formatting. The latter example is so bad that you can't use assembly binding redirects, and are forced to update to a newer dependent package (which may force more package updates, starting the chain all over again). The process is very time consuming, just for the purpose of using a more recent library in an module.

I also have some concern with relying on a patched library that effectively halts your ability to take new versions of that product. Is there some documented explanation for why this is needed and why it isn't fixed in the mainline of NHibernate? I know this seems like a digression but you are using it as an argument against making managing versions of dependencies easier. I'd like to better understand why this is a blocker, and why Orchard hasn't considered moving to a different ORM if it's essentially stuck on an old version.
Mar 8, 2015 at 8:33 PM
I don't know the story behind the NHibernate custom build, it was done by Sebastien (pinged him to chime in here) a long time ago. Maybe a later release already fixed this.

If you have the necessary resources to spend then by all means try to move Orchard's dependencies to NuGet references. If it works then awesome. I'm just sceptical that the end result will be easier to maintain in the particular use-case of Orchard (I'm not arguing against package managers), I've told everything I have to say here.