LibrarySites.Banner

Feedback request: NuGet support and Sitecore

There are at least a couple of (unofficial) NuGet-related solutions available for Sitecore. The solutions I know of are:

What are your thoughts on those solutions? Apart from having Sitecore provide an official NuGet server that provides packages for Sitecore, are there things you'd like to see added to these solutions to make them better, easier to use, etc?

Adam Conn

47 Replies

  • Sean Holmesby

    Personally, I love both of these solutions.
    The push for Nuget packages is a logical one with Sitecore development.


    I'd like to see at least a packages.config of just third party, publicly available packages that each Sitecore version uses.
    Maybe this is something Sitecore don't mind releasing with each version?

    i.e Newtonsoft.Json is 4.5.9 in Sitecore 7.1, but 6.0.5 in Sitecore 8.0.

    That way we could easily align our own third party packages with the version of Sitecore we're on, and not mess with assembly redirects.

    From that, we could also structure the Sitecore package definitions from the above solutions to use these 3rd party packages as dependencies.

    i.e Sitecore.Mvc depends on Microsoft.AspNet.Mvc (v4.0.30506 in Sitecore 7.1, v5.x.x in Sitecore 8.0)

  • Sean Holmesby

    Here's some structuring of Nuget Packages I would like to see.

    These have been structured based off the two repositories mentioned above, feedback from my own dev team, and some other blog posts I've found around the place.

    If anyone has feedback on these, please let me know.

    Sitecore.Core

    DLLS
    - Sitecore.Kernel.DLL

    Dependencies
    - Newtonsoft.Json (compatible version)???

    Sitecore.Client

    DLLS
    - Sitecore.Client.DLL

    Dependencies
     -

    Sitecore.Analytics

    DLLS
    - Sitecore.Analytics.DLL
    - Sitecore.Analytics.Automation.DLL
    - Sitecore.Analytics.Core.DLL
    - Sitecore.Analytics.Model.DLL
    - Sitecore.Mvc.Analytics.DLL

    Dependencies
    -

    Sitecore.ContentSearch

    DLLS
    - Sitecore.ContentSearch.DLL
    - Sitecore.ContentSearch.Linq.DLL

    Dependencies
    - Sitecore.Core

    Sitecore.ContentSearch.Analytics

    DLLS
    - Sitecore.ContentSearch.Analytics.DLL

    Dependencies
    - Sitecore.Analytics
    - Sitecore.ContentSearch

    Sitecore.Mvc

    DLLS
    - Sitecore.Mvc.DLL

    Dependencies
    - Sitecore.Core
    - Microsoft.AspNet.Mvc (compatible version)

    Sitecore.Mvc.Analytics

    DLLS
    - Sitecore.Mvc.Analytics.DLL

    Dependencies
    - Sitecore.Mvc
    - Sitecore.Analytics

    Sitecore.ExperienceEditor

    DLLS
    - Sitecore.ExperienceEditor.DLL
    - Sitecore.ExperienceEditor.Speak.DLL

    Dependencies
    - Sitecore.Client

    Sitecore.Buckets

    DLLS
    - Sitecore.Buckets.DLL

    Dependencies
    - Sitecore.Core

    Sitecore.Configuration

    DLLS
    - Sitecore.Logging.DLL

    Dependencies
    - Sitecore.Core
    - Lucene.Net (compatible version)

    Sitecore.Packaging

    DLLS
    - Sitecore.Update.DLL
    - Sitecore.Zip.DLL

    Dependencies
    - Sitecore.Core
    - Sitecore.Configuration

    Sitecore.Speak

    DLLS
    - Sitecore.Speak.Client.DLL
    - Sitecore.Speak.Mvc.DLL

    Dependencies
    - Sitecore.Mvc

    Sitecore.Services.Core

    DLLS
    - Sitecore.Services.Core.DLL

    Dependencies
    -

    Sitecore.Services

    DLLS
    - Sitecore.Services.Client.DLL
    - Sitecore.Services.Infrastructure.DLL
    - Sitecore.Services.Infrastructure.Sitecore.DLL

    Dependencies
    - Sitecore.Services.Core
    - Sitecore.Core
    - System.Net.Http (compatible version)
    - Microsoft.AspNet.WebApi (compatible version)
    - Microsoft.AspNet.Cors (compatible version)
    - Microsoft.AspNet.Mvc (compatible version)

  • Richard Seal

    In reply to Sean Holmesby:

    That's a great and pretty comprehensive list . It's pretty close to the packages that we use at Lightmaker, although you have more of them - it would be a great thing if Sitecore published out those as Nuget packages with each release!

    I don't think there would be any conflict with making those publicly available - or maybe Sitecore could host a private Nuget repository and give partners access to it. I don't think it should be limited to just certified devs, there are a lot of good non-certified Sitecore devs out there!
  • Sean Holmesby

    In reply to Richard Seal:

    Thanks Richard. Unfortunately I don't think that will ever happen.
    So... in lieu of a central repository.... I'm hoping, as a community we can come up with a standard.

    The standard could be used by the Nuget package generators Adam mentioned above.

    Then, everyone can have their own internal repository from their generated packages, which use the same standards.
    Shared Git code could then have in the gitignore 'packages/Sitecore*', and developers could just restore the packages from their private repo.
  • Richard Seal

    In reply to Sean Holmesby:

    Sounds like a good plan to me!
  • Adam Conn

    In reply to Sean Holmesby:

    I'm happy to modify my package to accommodate your suggestions. And I agree, I think creating a de facto standard is the best option right now.
  • Nick Wesselman
    Not sure how relevant it is to anyone else, but at Active Commerce we are using a modified version of Alen's solution, and one thing we add to the Sitecore.Kernel package is a copy of the Web.config for that version of Sitecore. We copy this into the web project on build as Sitecore.Web.config, then use SlowCheetah to apply a transform to add our config changes, and output the Web.config (that can then be further transformed for debug, release, etc).

    Advantage for AC is the ability to build against multiple versions of Sitecore by changing the nuget version that's referenced. For more common project work, I imagine it would make for easier upgrades (vs diff/merge against a modified Web.config).

    Not sure how that would work with your solution Adam, since the Web.config in the Sitecore install would be the deployed/modified version.

    Nick
  • Richard Seal

    In reply to Nick Wesselman:

    That's a good idea too - Although I would modify it to automatically break out the Sitecore section into App_Config/Sitecore.config like its now done in 8.1.

    We've been doing that for a long time now, I'm surprised it took Sitecore so long to make it OOTB!.

    How would you handle all the include files tho? Normally I do not add those to my project. I only have the projects own include files that patch the Sitecore ones. None of the Sitecore files should ever be modified directly - that just makes upgrades a nightmare! I just install Sitecore and then deploy my changed files to the installed instance.
  • Nick Wesselman

    In reply to Richard Seal:

    We do everything we can through patching as well, and do not have the base Sitecore App_Config\Include files in our project. However there are some aspects of the Web.config that can't be patched, and thus are good candidates for SlowCheetah transforms. For example, we add appSettings, apply log4net changes, add HTTP modules and handlers, and add some MVC output cache settings.

    You could definitely automate the breakout of the Sitecore section of the config as well... not sure if it could be done with SlowCheetah but certainly MSBuild or PowerShell.

    Nick

  • Jeremy Davis
    Having started down this road ages back, I've been using a home-grown process for packages. To be honest, it's past time I should be moving on to adopting one of these better approaches, but inertia (and lack of time to change something that's currently working OK) means I've not quite got there yet. A community standard around this sort of thing would be very positive, I think - and would be good leverage to make me move to a more recent approach.

    Sean's comments about the issues of dealing with the dependencies is a good point. The json library version has bitten me a few times on previous projects. And his breakdown of packages is a pretty similar model I've been trying, so I'd second addressing that.

    Also Nick's suggestion around including the web.config mirrors something I had experimented with. Since the base config is related to the DLL versions, it makes sense to me to include them from the same source.
  • Alen Pelin

    Latest version of bitbucket.org/.../sitecore-nuget-packages-generator is already embedded into SIM 1.4 Update-2 (beta) and offers all assemblies in separate packages so you can include only those you really need:
    PS> Install-Package SC.Sitecore.Kernel -Version 8.1.0.151003
    PS> Install-Package SC.Newtonsoft.Json -Version 8.1.0.151003

    This approach is granular so you get only what you want, no unnecessary packages.

    I am going to add some group packages as per described here bitbucket.org/.../implement-more-dependent-packages:

    SC-Sitecore = SC.*Sitecore*
    SC-Social = SC.*Social*
    SC-Client = SC.*Client*
    SC-Analytics = SC.*Analytics*
    SC-MVC = SC.*MVC*
    SC-Speak = SC.*SPEAK*
    SC-ContentSearch = SC.*ContentSearch*
    SC-System = SC.*System*
    SC-Lucene = SC.*Lucene*
    ...

  • Sean Holmesby
    How do people feel about the granularity of the packages defined above?

    I know has looked at just making the packages so granular they're one DLL per package.
    That would make it similar to the Microsoft WebApi packages.... but maybe we could add dependencies like the WebApi packages do.

    i.e Sitecore.ContentSearch.Linq, depends on Sitecore.ContentSearch, which depends on Sitecore.Kernel.

    I think the third party packages should reference the publicly available packages though. We've seen issues where the Newtonsoft.Json.DLL was included in a custom package, and then added directly in the public package elsewhere.
  • Richard Seal

    In reply to Sean Holmesby:

    1 DLL per package would give the ultimate in flexibility, but seems a bit too fine grained to me, I think some grouping is fine. How often are you going to need ContentSearch without ContentSearch.Linq? Just an opinion tho. I would be happy with 1 DLL per package, just not sure we need it.
  • Charlie Turano

    In reply to Sean Holmesby:

    I like the idea of grouping the DLL's in packages based on their function as Sean suggested. i.e. Kernel, Analytics, Content Search, etc. I wouldn't include external dll's like newtonsoft, but I would add dependancies to the correct NuGet package versions.

    I see a few problems with 1 dll per package:

    1) I have to add each one manually just like the good old days with references.
    2) If I upgrade Sitecore and there is a new dll, I need to add it to all my solutions. This isn't all that hard, but if it was part of the Analytics NuGet package I'm using, I wouldn't have to worry about it.
    3) It seems like more opportunity to make a mistake with accidentally mixing Sitecore versions.

    Can anyone tell me what the benefit of having one dll per NuGet package is?

    Thanks!

    Charlie
  • Richard Seal

    In reply to Charlie Turano:

    It gives a lot of flexibility. If you set the dependencies for each package correctly - upgrading shouldn't be too much of a problem, Nuget could handle most of that.

    The versions of the Nuget Package should match the Sitecore Version they support. Then installing a specific version would be as simple as

    Install-Package Sitecore.Kernel -Version 8.1



    And updating just as easy.

    But I still think some could be grouped together.