How to reference and deploy Sitecore hotfix DLLs?

On By kiranpatilsIn Hotfix, Sitecore

Challenge

Recently we were facing 503 error on our Sitecore 9.0.2 version Sitecore App deployed on Azure App (Blog on that topic soon)

We reached out to our common friends — Sitecore Support team and they gave me Two Hotfix DLLs :

  • Sitecore.Kernel
  • Sitecore.ContentSearch

Til this point of time, I got DLLs like Sitecoe.Support.SOMNUMBER.DLL and it was easy to deploy. I can copy in Assemblies/Lib folder in your directory, and reference it from your Project. And it will be deployed on higher environments.

But If you are wondering how to do it for these two DLLs? As they are coming from Sitecore’s Nuget feed in your current solution. Are you? Then this post is for you.

Solution

As you do, I also did a quick search and foud this from Sitecore’s official doc : https://doc.sitecore.com/developers/82/sitecore-experience-platform/en/sitecore-public-nuget-feed-faq.html

That was disappointing 😦 Then thought to reach out to our internal Sitecore experts and following great ideas came up:

  1. Private Nuget server : This makes sense. But have to reach out to client and ask them to spin up new nuget server and deploy DLL there. But was unable to figure out, how it will resolve from nuget references [Sitecore] and Custom nuget having same DLLs with same name.  As I was not clear and had client team’s dependencies thought to look for other solution.
  2. Local Reference : Another plan was to use old school approach, Where you created Assemblies/Libraries/Libs folder under your Project directory and instead of nuget use local reference in all your projects. But it had two challenges:
    1. We are using Helix and we have lot of projects, where we need to do these updates ~20. Which I was not sold.
    2. In future, If we have to do version upgrade. We have to again do these changes manually for all projects. Lot of work Now and in future – not efficient. So, thought to think of another approach
  3. Post build step : Another idea was to provide post build steps in last project, which copies hotfix’d DLLs. That could have fixed local development environment challenges. But we use Teamcity, Octopack and Octopus deployment and this idea would need additional steps from DevOps team. Which is fine for now. But in future — Same efforts needs to be done to undo it. So, this was also not a good idea.

Then I applied my 99 things learning, Step away from keyboard : https://github.com/97-things/97-things-every-programmer-should-know/blob/master/en/thing_69/README.md

And got a new idea:

By default nugget looks for DLL file from Packages folder and if exist, it doesn’t download and uses it as a reference DLL. For example : Sitecore.Kernel.DLL can be found under <YOURPROJDIR>\packages\Sitecore.Kernel.NoReferences.9.0.180604\lib\NET462

This was Eureka moment. Where I thought to do this:

  1. Copy new DLL from Sitecore hotfix package and pasted it under
    <YOURPROJDIR>\packages\Sitecore.Kernel.NoReferences.9.0.180604\lib\NET462
  2. Committed : Packages folder and
    Sitecore.Kernel.NoReferences.9.0.180604\lib\NET462 folders
  3. That’s it!
  4. it worked on Local – Teamcity and Octopus!

This helped? You found better approach than this? I’m all ears!

Happy Coding! 🙂

Update:

Somehow, I haven’t done good job sharing context of this blog post. Got some comments and thought to share it here. So, this post’s information is relevant:


The best solution (In the best case scenario) is to have Filesystem based/Private Nugget server : https://docs.microsoft.com/en-us/nuget/reference/nuget-config-file

5 thoughts on “How to reference and deploy Sitecore hotfix DLLs?”

  2. This feels very wrong and goes against the very point of NuGet. You really should not be checking in the /packages folder into source control (the suggested VS .gitignore even excludes this by default) and certainly should not be modifying the contents of the packages folders like this anyway.If you’re going this route then you are better with option 2, and local references in /lib folder or something.

    The better solution, if you do not have access to a private nuget server, is to use a local folder based package reference instead, and check that into in source control. You can then just delete the package or remove the config entry later.

    https://docs.microsoft.com/en-us/nuget/reference/nuget-config-file#packagesources

    I assume that everyone is using a solution specific nuget.config file these days, just add another package folder to a local folder and drop the nuget file in there. The folder location can be a relative path location too.

    Reply
  3. markloweschweiz

    Interesting post although in my opinion the packages folder should never be included in the repository. Management of this folder should be ONLY the package managers responsibility. The only clean way to do it is to set up your own nuget server and create and publish your packages there. And even if that isnt possible in your organization for whatever reason, I’d still prefer placing the assemblies in a libs folder in your repo over manually overwriting files in the packages folder.

    Reply

Leave a comment