Orchard as a NuGet package

Topics: Announcements, Core
Developer
Aug 6 at 10:17 AM
During the last meeting the idea for having Orchard as a NuGet package came up. I think this would be great and add some flexibility to enable new usage scenarios. Not to mention it would also make using Orchard together with the Orchard App Host trivial in any application.

I think the main task here would be to have Orchard.Framework and maybe Orchard.Core as NuGet packages (maybe both as source and compiled) so you could use them in an arbitrary project. This would possibly allow easier Orchard upgrade too. However we should also handle Web.config or possibly other config changes if these are added to a web project (as this would enable you starting an arbitrary new web project and then add Orchard later).

Another related, but probably independently solvable idea would be to have full support for modules in form of NuGet packages.

FYI somebody already tried this.
Aug 6 at 12:16 PM
+1

Really cool to have as a NuGet package. I think updating would also be a lot easier.
Developer
Aug 6 at 9:13 PM
+1000

If people can update Orchard through Nuget, that would be epic.
Developer
Aug 6 at 9:19 PM

Omg yes. It would seriously help adoption.

Aug 9 at 4:11 PM
I hope that Orchard won't depend on NuGet - so far we've seen NuGet only as a big trouble maker in team development and it's therefore banned for our developers.
Developer
Aug 9 at 4:21 PM
Could you share some specifics? What are your experiences?
Aug 9 at 7:21 PM
Sounds weird. At first glance the two - NuGet and Team Development - don't have anything to do with each other
And even if it would. Having NuGet packages dosen't mean that existing upgrade Szenarios wouldn't exist anymore,. So what

+1
Developer
Aug 9 at 7:33 PM
Edited Aug 9 at 7:34 PM
You can totally bring together NuGet and team development, you can have your own package source for example to share libs and parts of the application between teams (LogMeIn does that for example). It's the same deal as if you had your private Orchard gallery.
Aug 9 at 7:37 PM
Our last try is about a year old and not related to Orchard, So things might have changed. But the initial problem was that on different developer machines we got different versions of dependencies without any obvious reasons. So we never managed to have a well defined, documented, identical environment on all development, test and build systems.

We need to verify the license terms of any 3rd party component we use, so all 3rd party files need to be approved before they can be used. With NuGet we frequently had files suddenly appearing as a new dependency or license terms had been changed without any notice. We once even got a GPL licensed file used for a short time. So from our point of view NuGet is a nightmare if you want or need to care about IP rights.

We absolutely prefer to current Orchard approach - have a central repo or folder (like lib) with approved, tested and supported dependencies any developer can use without any worries.
Developer
Aug 9 at 7:41 PM
My understanding is, as I initially thought, that having an option to use Orchard from NuGet in some ways (whatever that be) should only be just another option.

Using the full solution will remain for the foreseeable future IMO: obviously we need it for the development of Orchard itself, but the lib folder is also justified by a) having some libraries not distributed as NuGet packages and b) we using some custom builds from external libs.