Sitecore Xperiences » Upgrades

Automatic Sitecore NuGet upgrades with Powershell

Rodrigo Peplau — Tue, 02 Nov 2021 02:05:18 +0000

One of the most tedious tasks in any Sitecore upgrade is to update your NuGet references. If your projects have so many NuGet references on packages.config, and in special with Helix solutions, updating everything manually can take you several hours.

To the rescue, I’ve created this Powershell Script, which you can use to save your precious time.

What you need to download:

The Powershell Script itself
The CSV file with all Sitecore references from this article – Direct link to the CSV file itself is here.
This file is valid for Sitecore 10.1 – if you need a different version, you will have to prepare and use a different CSV file (Read the article to learn more)

Steps to update each project in your solution:

Step 1 – If your upgrade requires, update your Project to the target .NET Framework
Step 2 – Get the NuGet commands to update your project.
Step 3 – Run the NuGet commands at the Package Manager Console of Visual Studio

It is recommended to update the references gradually, so you can detect and fix any issue as you continue.

In my experience, the following sequence produced good results:

If your .NET Framework has changed due to the upgrade, re-install all references not used by Sitecore by running the following command:

.\Update-PackagesFile.ps1 -Csv “C:\temp\NuGet Sitecore.Platform.Assemblies 10.1.0 rev. 005207.csv” -Packages “D:\Git\myproject\packages.config” -ProjectName “MyProject” -DumpUnknownReinstall $true
Update the 3rd party references to the target versions, and using this command:

.\Update-PackagesFile.ps1 -Csv “C:\temp\NuGet Sitecore.Platform.Assemblies 10.1.0 rev. 005207.csv” -Packages “D:\Git\myproject\packages.config” -ProjectName “MyProject” -DumpKnownReinstall $true
Sometimes 3rd party reference versions didn’t change, but you still want to force them to reinstall. If that’s your case, use the command:

.\Update-PackagesFile.ps1 -Csv “C:\temp\NuGet Sitecore.Platform.Assemblies 10.1.0 rev. 005207.csv” -Packages “D:\Git\myproject\packages.config” -ProjectName “MyProject” -DumpKnownReinstall $true
Finally, uninstall and re-install your Sitecore references (useful when migrating from earlier versions into SC10):

.\Update-PackagesFile.ps1 -Csv “C:\temp\NuGet Sitecore.Platform.Assemblies 10.1.0 rev. 005207.csv” -Packages “D:\Git\myproject\packages.config” -ProjectName “MyProject” -TargetSitecore “10.1” -DumpSitecoreUpdates $true

or simply update them with this command:

.\Update-PackagesFile.ps1 -Csv “C:\temp\NuGet Sitecore.Platform.Assemblies 10.1.0 rev. 005207.csv” -Packages “D:\Git\myproject\packages.config” -ProjectName “MyProject” -TargetSitecore “10.1” -DumpSitecoreUpdates $true -KeepSitecoreLibs $true

Full description of parameters:

Csv (mandatory) – Path to the CSV file
Packages (mandatory) – Path to the packages.config file
ProjectName (mandatory) – Project Name
TargetSitecore – Target Sitecore version
DumpUnknownReinstall – If $true => Will dump the Update-Package with -reinstall commands for libraries not used by Sitecore
DumpKnownUpdates – If $true => Will dump the Update-Package commands for known libraries when versions doesn’t match
DumpKnownReinstall – If $true => Will dump the Update-Package with -reinstall when versions are the same
DumpSitecoreUpdates – If $true => Will dump the Update-Package for Sitecore.* libraries
KeepSitecoreLibs
- If $true => then the Sitecore entries will NOT be uninstalled (Update)
- If $false => then the Sitecore entries will be uninstalled and re-installed (useful when migrating from earlier versions into SC10)

Language specific MediaProvider breaking icons at Media Library

Rodrigo Peplau — Tue, 14 Feb 2017 15:00:30 +0000

UPDATE: Kamruz Jaman has contributed with a comment for a simpler, less intrusive and more generalist solution: Inside the GetMediaUrl method of your custom MediaProvider, check for the “Thumbnail” property of your MediaUrlOptions parameter. If it is true, make your code fall back to the base, such as:

if (mediaOptions.Thumbnail)
return base.GetMediaUrl(mediaItem, mediaOptions);

During an upgrade from Sitecore 6.5 to Sitecore 8.1 one issue were noticed at the Media Library: when a Media Item is uploaded, the icon appears broken.

A custom MediaProvider is used at this build to modify the way Sitecore generates Media Item urls. All it does is to add the language at beginning of the media URL so we can have language-specific media items. This is important to allow the same Media Item (etc: an image or PDF) to be served in multiple languages.

Root cause

When a media item is uploaded to the Media Library, Sitecore will fill the “Icon” field with the URL of the media item itself. Because of the custom MediaProvider, language is being added to the beginning of the generated URL. Apparently that was not a problem in Sitecore 6.5, but things seems to have changed at Sitecore 8.

Technical explanation by Sitecore

A Support Ticket #476256 were created to allow further investigation from Sitecore on this issue. According to the technical team:

“The behavior you reported is expected as tree node icons are rendered by Sitecore.Shell.Applications.ContentManager.Sidebars.Tree.RenderIcon(Item item) method which does not use language definition, embedded to URL, to resolve item language. So when the Icon field contains URL with language definition embedded, it breaks the method functionality and leads to incorrect resolution of the item’s icon.

When you have versioned media item, the icon is rendered for specific language automatically even when language is not specified deliberately. For instance, if you have media item with two language versions and different images for each language, and use -/media/ItemGUID.ashx?h=16&thn=1&w=16 string in the Icon field, language specific icon will be rendered when you switch the language in the Content Editor.”

This explains the causes but doesn’t fix the issue: how can we skip or bypass the custom MediaProvider, avoiding the language to be added to the URL when the “Icon” field is filled?

Solution

In order to fix that we will need to extend and override the Sitecore.Resources.Media.Media class, responsible for the upload and update of metadata when a Media Item is uploaded to the Media Library, then modify all Media Types to use your class instead of the original.

Step 1 – Extend the Media class

This is going to be responsible for removing the language from the URL when a Media Item is uploaded. In bold you see the code responsible for that, rest is basically native code to ensure compliance with default Sitecore behavior.

using Sitecore;
using Sitecore.Configuration;
using Sitecore.Data.Items;
using Sitecore.Data.Proxies;
using Sitecore.Diagnostics;
using Sitecore.Resources.Media;
using Sitecore.SecurityModel;

namespace CustomMediaProvider
{
  public class Media : Sitecore.Resources.Media.Media
  {
    public override Sitecore.Resources.Media.Media Clone()
    {
      return new Media();
    }

    public override void UpdateMetaData(MediaStream mediaStream)
    {
      Assert.ArgumentNotNull(mediaStream, "mediaStream");
      var innerItem = MediaData.MediaItem.InnerItem;
      if (!innerItem.Paths.IsMediaItem) return;
      using (new EditContext(innerItem, SecurityCheck.Disable))
      {
        innerItem["extension"] = mediaStream.Extension;
        innerItem["mime type"] = mediaStream.MimeType;
        innerItem["size"] = mediaStream.Length.ToString();
        if (Settings.Media.AutoSetAlt)
        {
          innerItem["Alt"] = innerItem.Name;
        }
        var shellOptions = MediaUrlOptions.GetShellOptions();
        shellOptions.Thumbnail = true;
        shellOptions.Height = 0x10;
        shellOptions.Width = 0x10;
        var realItem = ProxyManager.GetRealItem(innerItem, true);
        // CODE ADDED TO REMOVE LANGUAGE FROM URL WHILE UPLOADING
        var iconUrl = MediaManager.GetMediaUrl(realItem, shellOptions);
        var prefix = "/" + Context.Language.Name + "/";
        if (iconUrl.StartsWith(prefix)) iconUrl = iconUrl.Replace(prefix, "");
        innerItem.Appearance.Icon = iconUrl;
      }
    }
  }
}

Step 2 – Register the Media class to all Media Types

This is the painful part: we will need to register our class to every Media Type we want to cover. There is no easy way for that other than adding a node for each Media Type, paying attention to the correct way for patching that specific node (some nodes may have a Media class already defined and thus needs correct patching, others don’t).


 
 
 
 
 CustomMediaProvider.MediaProvider,CustomMediaProvider

Workflow not starting (state field is empty) when Versions.AddVersion after Sitecore upgrade from 6.5 to 8.1

Rodrigo Peplau — Wed, 23 Nov 2016 22:19:18 +0000

UPDATE: A ticket at Sitecore Helpdesk demonstrated the issue happened to be something else. During the upgrade, the site definition we’re using got the attribute “enableWorkflow” removed, which in turn made the default value “false” take over, and that was causing ALL WORKFLOWS to be simply ignored.

If your site does have enableWorlflow=”true” then you don’t need to manually start workflows as shown in this article

After an upgrade, a certain code was simply not working as expected anymore. When you create a new version of an item (item.Versions.AddVersion), whose _Standard Values had a Default Workflow setup, the workflow simply was not starting, and thus the “State” field gets empty. The very same code, at the non-upgraded version, works perfectly.

Looking at the code, it was never touching Workflows, suggesting that Sitecore would be automatically handling the thing. Since it was an upgrade, I lost myself investigating for things I could have left behind: Pipelines, Scheduled Tasks, etc.

And I then discovered it was Sitecore that changed the way how the API acts… a change that made me struggle in for almost a week! And I just learned that when I decided to create a small script to run the same code on both 6.5 and 8.1 instances.

The code was getting an item by it’s ID, adding a version and printing the number of the newly created version:

Sitecore 6.5

When I run that on 6.5, which has 5 versions before:

The new version is created:

And the State is correctly filled:

Sitecore 8.1

However when I run it on 8.1, which previously had 39 versions:

The 40th version is created, but the State field is empty!

Solution

So what I had to do, to make the same code run correctly on 8.1, was to force the item thru the workflow after a new version is created. That screw hard to find, easy to twist:

Item newVersion = myItem.Versions.AddVersion();

var defaultWorkflow = newVersion.Fields[FieldIDs.DefaultWorkflow].Value;
ID defaultWorkflowId;
if (!ID.TryParse(defaultWorkflow, out defaultWorkflowId))
    return;

var workflow = newVersion.Database.WorkflowProvider.GetWorkflow(defaultWorkflowId.ToString());
if (workflow!=null)
    workflow.Start(newVersion);