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?

47 Replies

  • In reply to Richard Seal:

    I really don't see where the flexibility comes from. I can't say I don't want Sitecore.Kernel if I've included Sitecore.Analytics. If the packages are grouped nicely by function, as Sean specified, there will not be many references you don't need.

    If we are stitching everything together with dependencies, then why not keep them grouped together. I always though dependencies were designed for components that were logically separate or made by different organizations. e.g. Newtonsoft is used by Sitecore.

    If it is a question of managing any new dll's as Sitecore moves forward, it seems like it will be just as much effort to manage the dependencies.

    Thanks

    Charlie
  • In reply to Charlie Turano:

    In this conversation there are a lot of "I like", "I prefer", "It is bettter" and so on, but we cannot define a set of nuget packages that everybody will love. However making them granular (each dll in its own package) solves the problem of not having any packages at all. Having them granular will satisfy everybody because it is flexible and situation where you just don't have required dll is impossible.

    In my experience, I have never needed more than 5 assemblies of Sitecore distributive, and in my last 100 projects the sets were different, but all of them included Sitecore.Kernel and it was the only assembly that was included in all of them. You always know what assembly do you need, and typically you need only 1 assembly at once - when you add new functionality. Lets say ContentSearch, you add all ContentSearch dlls, but then ReSharper tells you that you actually need only one or two of them - all the rest are just unnecessary.

    My vision that we should focus on MVP (minimal viable product) and granular packages are just what we need.

    I agree however that all non-Sitecore.Kernel packages should depend on Sitecore.Kernel as this assembly is required at all times. I will add this to issues tracker.

  • In reply to Alen Pelin:

    So there are good ideas that have been listed here. How do we go about making a standard and then getting that standard out there?
  • In reply to Richard Seal:

    What about a github repo like the Airbnb Style Guide (github.com/.../javascript) - Define the standard there and link through to the tools for that, like the package generators that listed?
  • In reply to Charlie Turano:

    , how would you recommend one handles SitecoreAssemblyPath on the TDS project properties when Sitecore DLLs are referenced via packages (delivered via NuGet)? Typing a path to the packages folder with all the versions in it isn't exactly as "easy" (and portable between diff Sitecore versions) as typing ..\Libs\Sitecore, for example.
  • In reply to Pavel Veller:

    I was just thinking about this the other night. It made my head hurt a bit. The best thing I came up with is to use a relative path to the /bin folder of a class project or web project that references the correct stuff. This way, NuGet sets the references, MSBuild pulls the .dll's into the /bin folder and the package builder finds them there. This will work with the current version and as long as the TDS project depends on the project you are referencing, you should be good. This can even be an empty project that isn't referenced by any other projects.

    I'm trying to think of a better way to find these. Ideally, I would just find them based on the packages you included in the solution, but that will not work today.

    Hope this helps

    Charlie
  • In reply to Charlie Turano:

    Yep, makes sense, thanks . I also think that you can't do based on the packages, not until we have a standardized (and ideally provided by Sitecore) set of nuspecs. As long as we all bake our own Sitecore NuGet packages there's no convention you can lean on.
  • In reply to Pavel Veller:

    I suspect I can just go look for the 4 assemblies I need and load them. I'm planning on giving this more thought after I finish the feature I'm currently working on. I agree that it would be much easier if we had a standard.

    Thanks!
  • In reply to Pavel Veller:

    Not sure it's a "clean" approach but our Sitecore.Kernel package just includes everything TDS needs, and similar to you Pavel, we have build properties that define the Sitecore version and revision. Then in TdsGlobal.config we have

      <PropertyGroup>
        <SitecoreAssemblyPath>..\packages\SitecoreKernel.$(SitecoreVersion).$(SitecoreRevision)\lib</SitecoreAssemblyPath>
      </PropertyGroup>
  • I see you've made some updates to your Nuget package generator.

    Out of interest, the naming convention using 'SC' instead of 'Sitecore'.... is there a particular reason for this?
  • In reply to Holmesby Sean:

    to avoid conflicts. For example, "Newtonsoft.Json" nuget package already exists in nuget.org and

    Install-Package Newtonsoft.Json -Version 8.1.0.151003

    may confuse both nuget and people. So with SC prefix it no longer causes a conflict and it is easier to understand that the version 8.1 relates to SC and not to Json.NET.

    Install-Package SC.Newtonsoft.Json -Version 8.1.0.151003

    And there is plenty of room for other assemblies conflicts, including the moment in bright future when there are official Sitecore NuGet packages on nuget.org. 

    I could use "Sitecore" instead of "SC", but "SC" is shorter and double Sitecore is ugly: "Sitecore.Sitecore.Kernel", "Sitecore.Newtonsoft.Json"

    Does it make sense? In addition, there is "SC" package that includes all of them. Just "Sitecore" may be confusing as it is not clear will it include "SC.Newtonsoft.Json" or not - "SC" will definitely do. 

  • In reply to Alen Pelin:

    Hmmm ok.
    So, I was thinking we should only create packages for Sitecore* DLLs.
    Other DLLs (like Newtonsoft) should come from their own public packages. (although some DLLs in Sitecore don't have these).
    I would prefer this... so two DLLs for Newtonsoft can't originate from separate locations on my file system. This has been an issue with other solutions in the past.

    I have some code that detects this....but really, we only need the public versions of Newtonsoft.Json, Microsoft.AspNet.Mvc and Microsoft.AspNet.WebApi.

    Also.... I understand the risk of clashing with an 'official' feed.... but lets be honest.... I doubt that's gonna happen. hahaha.
  • In reply to Holmesby Sean:

    Not all other DLLs are available as nuget packages with necessary versions and it is hard work to find all of them. And as a developer, I don't want to think what version of Newtonsoft.Json I need for 8.1 - I just need the same that ships with 8.1
  • In reply to Alen Pelin:

    I think that's where a problem lies.

    As a developer, a person should not be ignorant of the versions of packages that should be used and are recognized as compatible for that version of Sitecore.
    For Newtonsoft.Json, a developer might install WebApi, which Microsoft have defined with dependencies... But we try to replicate it in our own way? Without dependencies?
    Microsoft dependencies state to pull in Newtonsoft.Json.... So say, then a developer uses that, and suddenly we have two packages, both containing Newtonsoft.Json.DLL.
    This is the story that I've seen too many times and landed me in Nuget / DLL hell.

    No, Sitecore doesn't use Nuget packages for some other things (Stimulsoft, Telerik etc), but it's not often I need to use those in my own solution anyway.

    I believe we should only package Sitecore.DLLs, and it's the only thing we should be Nuget-izing.
  • In reply to Holmesby Sean:

    Yet another reason why Sitecore should just figure out how to do public, or authenticated feeds.