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 Nick Wesselman:

    Sitecore is great in other things and inability to provide NuGet packages is not so severe as we can fix it simply with SIM. And we should let Sitecore do things we cannot fix ourselves. 

    P.S. Current version of NuGet package generator is already released with SIM 1.4 Update-2 (1.4.0.210) here: dl.sitecore.net/.../sim

  • I've begun extending the Nuget Package Generator to create the custom packages I mentioned earlier in this thread.
    These packages use the single DLL packages as dependencies....which just makes for quicker consumption, and allows a hybrid approach.

    As with all programming, naming these 'groupings' of packages is difficult. :-)

    I've added 'CoreGroup' to the end of each custom group package...
    bitbucket.org/.../PackageDefinition.cs;fileviewer=file-view-default

    I would just do 'Core', but it conflicts with package names of single DLLs. i.e Sitecore.Analytics.Core

    Anyone got suggestions for this?
  • In reply to Sean Holmesby:

    I've updated the code to search for third party Nuget packages on the public repository.
    This works when adding third party dependencies to custom packages. i.e Newtonsoft.Json, Microsoft.AspNet.Mvc

    The complete update can be found here:-
    bitbucket.org/.../sitecore-nuget-packages-generator

    I'll be making a pull request soon.... but would appreciate any further suggestions from people on the custom packages.
  • In reply to Sean Holmesby:

    For Sitecore.Services.Client your looking at these DLLs

    Sitecore.Kernel
    Sitecore.Services.Client
    Sitecore.Services.Core
    Sitecore.Services.Infrastructure
    Sitecore.Services.Infrastructure.Sitecore
  • In reply to Sean Holmesby:

    For SPEAK you don't need the DLL's for apps as its JavaScript based. But for custom components your looking at

    Sitecore.Speak.Mvc.dll
    Sitecore.Speak.Client.dll
    Sitecore.Kernel.dll
    Sitecore.Speak.Components.dll
    Sitecore.Mvc.dll
  • In reply to Mike Robbins:

    Thanks Mike.

    I've added these package groupings into the generator.
    bitbucket.org/.../84ebce770a66961807b4670e48cc4e467e8931dd

    Cheers,
    Sean
  • Hi,

    I have been using the Sitecore NuGet Packages Generator. It has generated all the NuGet packages for the stock Sitecore DLL's. However, I would have thought it would also generate packages for official modules, like WFFM or Solr support package. According to the documentation, there should be a GenerateSitecoreNuGetPackages.exe somewhere to create packages manually, but I can't find this file (due to SIM being a ClickOnce application?).

    Can the tool be extended so it generates packages for official modules as well?

    /cc

  • In reply to Thomas Dedeyne:

    Hi


    Latest version embedded into QA version of SIM (dl.sitecore.net/.../sim) supports WFFM and EXM because SIS (Sitecore Information Service) only supports them at the moment (dl.sitecore.net/.../info).

    Regards, Alen.

  • In reply to Alen Pelin:

    Thanks for your feedback, ! I've tried with the QA version but unfortunately I still don't see Nuget packages being generated for Sitecore.Solr.Support 1.0.0 rev. 151120.zip or Web Forms for Marketers 2.4.0 rev. 140117.zip. For Social Connected Module 2.1 rev. 140113.zip a package does get generated.

    Should I file an issue on GitHub regarding this?
  • In reply to Thomas Dedeyne:

    There are a couple of issues with older versions of some of the modules. Social Connected is part of the platform in 8.0+, but older versions of the module aren't supported at the moment.

    There are also some issues with older versions of Email Experience Manager (named Email Campaign Manager before 8.0).

    BTW, to find the location of SIM Click Once, I use this trick:-
    http://stackoverflow.com/a/9403378/1072657

          To find the folder location, you can just run the app, open the task manager (CTRL-SHIFT-ESC), select the app and right-click|Open file location.

    Also note that there are a fair amount of changes made in my branch (https://bitbucket.org/seanholmesby/sitecore-nuget-packages-generator) from what's currently used by SIM (https://bitbucket.org/sitecoresupport/sitecore-nuget-packages-generator). If Alen accepts my pull request, packages will be named Sitecore.Kernel, not SC.Sitecore.Kernel...and alike.
    This has been a request from a lot of people I've talked to in the community. As a consumer of the nuget packages, do you also agree with the name change?

  • In reply to Sean Holmesby:

    Nice trick with the Task Manager and the Open File Location thing! :) However, still no sign of GenerateSitecoreNuGetPackages.exe for stable and QA. Not that I really need it at this point.

    At the moment I only need the Solr Support package, the others were also in my repository folder and I just noticed they were missing as a NuGet package too. Sitecore.Solr.Support 1.0.0 rev. 151120.zip is still valid for the Sitecore version I'm working with (v8.1 update 1).

    Now, the SC prefix. There is something to say for both ways; I slightly lean towards no prefix because I prefer the public NuGet for things like Newtonsoft.Json. But as pointed out, if some non-Sitecore DLL's have no NuGet alternative, I would like to have them generated by the tool. I've read your pull request and it seems there is a parameter to let the user decide to use a prefix or not. So, in the end, it doesn't really matter, or does it? :)

  • In reply to Thomas Dedeyne:

    OK thanks.
    For the Sitecore Solr Support package, a work around at the moment is you could rename the zip locally to Sitecore 8.1 rev. 151120.zip (so the tool thinks this is a CMS package).
    The single DLL nuget packages would be generated for those DLLs then.

    As there are third party DLLs in there, as you mentioned, have a look into finding the third party packages for them instead.

    With my pull request, I left the parameter there for legacy, but believe it shouldn't be used. You don't want Newtonsoft.Json.DLL to end up in two different packages... that'll lead you down Nuget hell.
    But for the third party DLLs without associated packages (as listed here gist.github.com/.../d0f3b2adfff0acd9fc78), maybe there is some reason for it. I wonder how often these DLLs are used in development though? Are there any that you use as references in your code?
  • In reply to Sean Holmesby:

    I was thinking ahead and not limiting to my own situation. To be honest, I've never used any of those DLL's as a reference.

    Thanks for the workaround! It worked, although I had to use Sitecore 8.1 rev. 151207.zip as filename.
  • In reply to Thomas Dedeyne:


    The executable is missing because SIM doesn't use it. If you want it you should compile it yourself from sources. At the moment All CMS, Last WFFM and all EXM versions are the only products that are supported at the moment. All the rest will appear later when I am less busy.

    As for pull request, it is quite big so I need to find time to review it carefully and merge. So roughly a couple of weeks minimum.

    Regards, Alen

  • In reply to Alen Pelin:

    Ah damn, I was worried about that. I was hoping all the merging and rebasing that I did in my fork would mean an easy, 'auto-accept' merge back in for you.

    As it stands, my fork has your latest changes merged in. Maybe it'll be easier to check each of my commits one-by-one on my fork?

    Also, do you get notifications of comments posted about commits? I made a couple on your repo's commits recently but wasn't sure if you get notified of them.